文体问题:使用白色空间

Question

对于我的代码的美学,我有一种特别愚蠢的不安全感......坦率地说,我对白色空间的使用很尴尬.我的代码看起来像个极客; 不是很可怕,但很尴尬,你感觉不好盯着,但不能把目光移开.

我只是不确定何时应该留空或使用行尾注释而不是上面的注释.我更喜欢在我的代码之上发表评论,但有时候打破三个字评论的流程似乎很奇怪.有时在代码块之前和之后抛出一个空行就像在一个平滑的代码段中加速.例如,在嵌套循环中,在中心分隔三行或四行代码块几乎消除了缩进的视觉效果(我注意到K&R护腕比Allman/BSD/GNU样式更不容易出现这个问题).

我个人的偏好是密集的代码,除了函数/方法/注释块之外几乎没有"减速带".对于棘手的代码部分,我想留下一个大的注释块告诉你我将要做什么以及为什么,然后在该代码部分中添加一些"标记"注释.不幸的是,我发现其他人一般都喜欢慷慨的垂直白色空间.一方面,我可以拥有更高的信息密度,而另一些人则认为流量不是很好,另一方面,我可以以更低的信噪比为代价获得更好的流动代码库.

我知道这是一个小小的,愚蠢的事情,但这是我真正想要的工作,因为我提高了我的其余技能.

有人愿意提供一些提示吗？你认为什么是流动良好的代码,在哪里适合使用垂直空白？有关两行或三行评论的评论结束的任何想法？

谢谢!

PS这是我一直在研究的代码库中的方法.不是我最好的,但不是我迄今为止最差的.

/**  
 * TODO Clean this up a bit.  Nothing glaringly wrong, just a little messy.  
 * Packs all of the Options, correctly ordered, in a CommandThread for executing.  
 */  
public CommandThread[] generateCommands() throws Exception
 {  
  OptionConstants[] notRegular = {OptionConstants.bucket, OptionConstants.fileLocation, OptionConstants.test, OptionConstants.executable, OptionConstants.mountLocation};  
  ArrayList<Option> nonRegularOptions = new ArrayList<Option>();  
  CommandLine cLine = new CommandLine(getValue(OptionConstants.executable));  

  for (OptionConstants constant : notRegular)  
   nonRegularOptions.add(getOption(constant));  

  // --test must be first  
  cLine.addOption(getOption(OptionConstants.test));  

  // and the regular options...  
  Option option;  
  for (OptionBox optionBox : optionBoxes.values())  
   {  
    option = optionBox.getOption();  
    if (!nonRegularOptions.contains(option))  
     cLine.addOption(option);  
   }  

  // bucket and fileLocation must be last  
  cLine.addOption(getOption(OptionConstants.bucket));  
  cLine.addOption(getOption(OptionConstants.fileLocation));  

  // Create, setup and deploy the CommandThread  
  GUIInteractiveCommand command = new GUIInteractiveCommand(cLine, console);  
  command.addComponentsToEnable(enableOnConnect);  
  command.addComponentsToDisable(disableOnConnect);  
  if (!getValue(OptionConstants.mountLocation).equals(""))  
   command.addComponentToEnable(mountButton);  

  // Piggy-back a Thread to start a StatReader if the call succeeds.  
  class PiggyBack extends Command  
   {  
    Configuration config = new Configuration("piggyBack");  
    OptionConstants fileLocation  = OptionConstants.fileLocation;  
    OptionConstants statsFilename = OptionConstants.statsFilename;  
    OptionConstants mountLocation = OptionConstants.mountLocation;  

    PiggyBack()  
     {  
      config.put(OptionConstants.fileLocation, getOption(fileLocation));  
      config.put(OptionConstants.statsFilename, getOption(statsFilename));  
     }  

  @Override  
  public void doPostRunWork()  
   {  
    if (retVal == 0)  
     {  
// TODO move this to the s3fronterSet or mounts or something.  Take advantage of PiggyBack's scope.  
      connected = true;  
      statReader = new StatReader(eventHandler, config);  
      if (getValue(mountLocation).equals(""))  
       {  
        OptionBox optBox = getOptionBox(mountLocation);  
        optBox.getOption().setRequired(true);  
        optBox.requestFocusInWindow();  
       }  

      // UGLY HACK... Send a 'ps aux' to grab the parent PID.  
      setNextLink(new PSCommand(getValue(fileLocation), null));  
      fireNextLink();  
     }  
   }  
 }  

PiggyBack piggyBack = new PiggyBack();  
piggyBack.setConsole(console);  
command.setNextLink(piggyBack);  
return new CommandThread[]{command};  
}  

Answer 1

没关系.

1)开发自己的风格.无论你发现最简单,最舒适,做到这一点.尽量保持一致,但不要成为一致性的奴隶.拍摄约90%.

2)当您修改其他开发人员的代码或处理组项目时,请使用代码库中存在的样式约定或样式指南中已列出的样式约定.不要抱怨它.如果您能够定义样式,请提供您的偏好,但愿意妥协.

如果你遵循这两个你将全部设置.可以把它想象成以两种不同的方式讲同一种语言.例如:围绕你的朋友说话的方式与对你祖父的说法不同.

Answer 2

制作漂亮的代码并不是小事.当我写一些我真的很自豪的东西时,我通常可以退后一步,查看整个方法或课程,并一目了然地确实知道它的作用 - 甚至几个月之后.美学在其中发挥了作用,虽然不如优秀设计那么大.另外,意识到你不能总是编写漂亮的代码,(任何类型的ADO.NET都没有？)但是,如果可以,请做.

不幸的是,至少在这个更高的层次上,我不确定你是否有任何硬性规则可以始终产生美观的代码.我可以提供的一条建议是简单地阅读代码.很多.在许多不同的框架和语言中.