Стилистический вопрос: использование пустого пространства - PullRequest
4 голосов
/ 18 июня 2009

У меня особенно глупая неуверенность в эстетике моего кода ... мое использование пустого пространства, честно говоря, неудобно. Мой код выглядит как фанат танцев; не совсем пугающе, но достаточно неловко, чтобы тебе было плохо смотреть, но не можешь отвести взгляд.

Я просто никогда не уверен, когда мне следует оставить пустую строку или использовать комментарий в конце строки вместо комментария выше строки. Я предпочитаю комментировать выше моего кода, но иногда кажется странным прерывать поток комментариев из трех слов. Иногда бросать пустую строку до и после блока кода - это все равно, что помещать скачок скорости в другой плавный фрагмент кода. Например, во вложенном цикле, разделяющем блок кода из трех или четырех строк в центре, практически сводится на нет визуальный эффект отступа (я заметил, что браслеты K & R менее подвержены этой проблеме, чем стили Allman / BSD / GNU).

Мое личное предпочтение - плотный код с очень небольшим количеством «скачков» скорости, за исключением между функциями / методами / блоками комментариев. Для хитрых разделов кода я хотел бы оставить большой блок комментариев, рассказывающий о том, что я собираюсь сделать и почему, а затем несколько «маркерных» комментариев в этом разделе кода. К сожалению, я обнаружил, что некоторые другие люди обычно пользуются щедрым вертикальным пустым пространством. С одной стороны, у меня могла бы быть более высокая плотность информации, которая, по мнению некоторых, не очень хорошо течет, а с другой стороны, у меня могла бы быть более плавная кодовая база за счет более низкого отношения сигнал / шум.

Я знаю, что это такая мелкая, глупая вещь, но я действительно хочу работать над этим, улучшая остальную часть моего набора навыков.

Кто-нибудь хотел бы предложить несколько подсказок? Что вы считаете правильным кодом и где уместно использовать вертикальные пробелы? Есть какие-нибудь мысли по поводу комментариев в конце строки для комментариев из двух или трех слов?

Спасибо!

P.S. Вот метод из кодовой базы, над которой я работал. Не самый лучший, но далеко не самый плохой.

/**  
 * 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};  
}  

Ответы [ 13 ]

1 голос
/ 18 июня 2009

Мой предпочтительный стиль, вероятно, анафема для большинства разработчиков, но я буду добавлять случайные пустые строки, чтобы отделить то, что кажется подходящими «параграфами» кода. Это работает для меня, никто не жаловался во время проверки кода (пока!), Но я могу представить, что это может показаться произвольным другим. Если другим это не понравится, я, наверное, остановлюсь.

1 голос
/ 18 июня 2009

Я минимизирую пробел. Я поместил основной блок комментариев над блоком кода и дополнительными комментариями в конце строки к материалу, которые могут быть не очевидны для другого разработчика. Я думаю, что вы уже делаете это

0 голосов
/ 18 июня 2009

Мне нравится максимизировать объем кода, который можно увидеть в окне, поэтому я использую только одну пустую строку между функциями и редко внутри. Надеюсь, ваши функции не слишком длинные. Глядя на ваш пример, мне не нравится пустая строка для открытой скобки, но у меня будет одна для закрытия. Отступов и раскраски должно быть достаточно, чтобы показать структуру.

...