Подтвердить что ты не робот

Вы пытаетесь сделать ваш код красивым?

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

#divPreview {
    text-align: center;
    vertical-align: middle;
    border: #779 1px solid;
    overflow: auto;
    width: 210px;
    height: 128px;
    background-color: #fff"
}

теперь он выглядит следующим образом:

#divPreview {
    width: 210px;
    height: 128px;
    overflow: auto;
    text-align: center;
    vertical-align: middle;
    border: #779 1px solid;
    background-color: #fff";
}

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

if (0 < n && n < 10)

вместо

if (0 < n && 10 > n)

и, наконец, я буду стремиться упорядочить код if-then-else, чтобы часть THEN была меньше, чем часть ELSE (причина, что более тяжелый материал идет в нижнюю часть, справа?)

if (afflicted == true) {
  GetSome();
  HelpRight();
}
else {
  NowPlease();
}

тьфу!

if (afflicted == false) {
  HowMuchTrouble();
}
else {
  IsItToDo();
  ThisReally();
}

Aahhh

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

Вопрос: Я один в своем неврозе здесь? Какая у вас кодировка?

4b9b3361

ОТВЕТЫ

Ответ 1

Любой стиль кода, который заставляет вас изменять порядок вещей при неправильном изменении кода.

Это испортило бы разницу. Вы используете систему управления версиями правильно?

Есть еще несколько вещей, которые сделают ваш код красивее, но испорчу diff.

Представьте этот код:

int foo = 42;
int fooBar = 1024;

Теперь сделайте его красивее, выстроив знак =:

int foo    = 42;
int fooBar = 1024;

Но тогда мы добавляем другую переменную:

int foo              = 42;
int fooBar           = 1024;
String nowLetsBeEvil = 6400;

Теперь, если вы сделали diff, все 3 строки изменились, когда только последний сделал.

И там больше, выравнивание параметров между методами плохое

sqrt(x + y, x - z);
sqrt(x    , x    );

Комбинация запятой и точкой с запятой хорошо выровнена, но если вы когда-либо измените код, вам придется вручную переформатировать все строки sqrt, которые вместе, и снова испортить diffs.

В принципе, никогда не делайте ручного форматирования. Всегда применяйте стили кода, используя IDE или красивый принтер. Но также никогда не выбирайте стиль кода, в котором формат будет меняться, если ваш код не был

EDIT:

Как указано в комментариях, некоторые инструменты diff могут игнорировать пробелы внутри строк. Это здорово, но не все инструменты diff могут это сделать. Если вы выравниваете поля или параметры, убедитесь, что вы:

  • Не делать это вручную
  • Ваш инструмент diff может игнорировать изменения пробелов.

Ответ 2

По моему опыту, довольно хороший код обычно работает очень хорошо, в то время как уродливый код часто ломается в труднодоступных местах. Это правда, что вид ума, который обращает внимание на детали, как выглядит код, также является видом ума, который обращает внимание на более важные детали.

Тем не менее, переупорядочивание элементов в стиле CSS, чтобы они были короткими, - это летучая мышь ********, сумасшедшая.

Ответ 3

Положительное условие сначала в инструкции if-else, всегда. Красота лежит внутри.

if (afflicted) {
    GetSome();
    HelpRight();
} else {
    NowPlease();
}

Ответ 4

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

Порядок свойств CSS

#divPreview {
        width: 210px;
        height: 128px;
        overflow: auto;
        text-align: center;
        vertical-align: middle;
        border: #779 1px solid;
        background-color: #fff";
}

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

Порядок условных обозначений

Вы, например, здесь имеют смысл для меня, потому что он ясно показывает, что n находится между 0 и 10.

if (0 < n && n < 10)

Порядок блоков if/else

и, наконец, я буду стремиться if-then-else, чтобы THEN часть меньше, чем часть ELSE (потому что более тяжелый материал переходит к внизу, справа?)

Я думаю, что имеет смысл сначала иметь положительное условие (или более ожидаемое условие). И бит "== true" является избыточным.

if (afflicted) {
  GetSome();
  HelpRight();
}
else {
  NowPlease();
}

Ответ 5

Я бы, наверное, пошел еще дальше и сделаю следующее:

#divPreview {
        width            : 210px;
        height           : 128px;
        overflow         : auto;
        text-align       : center;
        vertical-align   : middle;
        border           : #779 1px solid;
        background-color : #fff";
            }

Ответ 6

он должен быть

if (!afflicted)
{
    HowMuchTrouble();
}
else 
{
    IsItToDo();
    ThisReally();
}

купить симпатичный принтер и получить лечение для OCD; -)

Ответ 7

Я рассматриваю его несколько иначе. Код должен быть отформатирован для удобочитаемости, не обязательно "Prettiness" - хотя эти два могут быть, как правило, одинаковыми.

но в качестве встречного случая

if(x != null)
    y=x.getParam();
else
    y=0;

является более читаемым, чем красивее:

y = x == null ? 0 : x.getParam();

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

На самом деле у меня даже были проблемы с рубином довольно элегантным:

y = x.getParam() if x

Просто потому, что я привык видеть контрольные утверждения, просматривая левую строку кода.

Я должен признать, что я немного расслабился в коленях, когда увидел этот синтаксис (я думаю, что он hascal)

y = x?getParam();

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

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

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

Кстати, в вашем первом примере были данные, а не код - данные очень нужны для форматирования - возможно, даже более того.

Ответ 8

Код должен быть легко читаемым. "Pretty" полностью согласуется с этими требованиями, если вы не слишком симпатичны с ним.

Ответ 9

Я перехожу за борт с моим форматированием OCD, но я по-прежнему считаю важным сохранить код максимально читабельным, если у вас нет действительно веской причины. Самая большая причина: код, который вы написали более 6 месяцев назад, может также быть написан кем-то другим. Сделайте себе одолжение и сохраните свой код в чистоте и согласованности.

Ответ 10

Ты не одинок:-) Я часто использую практику выравнивания (как в ответе Стива):

foo     = egg     + spam
foobar  = sausage + spam

Чем легче читать, тем лучше.

Еще одна небольшая вещь, которую я пытаюсь сделать систематически, - это сгруппировать термины в выражении в соответствии с приоритетом оператора, т.е.

if (a<b && c<d) ...
x = a*b + c*d

вместо

if (a < b && c < d) ...
x = a*b+c*d

Ответ 11

Мне нравится, что мой код тоже довольно, но не там, где он мешает читаемости.

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

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

И в CSS я предпочитаю "структурные" или атрибуты макета, чтобы я мог быстро увидеть, где что-то закончится, и только тогда, как это будет выглядеть. Я бы реорганизовал ваш первый пример CSS, чтобы выглядеть как ваш второй, но по моим причинам - не ваш.:)

Ответ 12

Многие вещи контекстуальны для меня.

Пробел или не в пространство...

   puts "ragu"+"pattabi"  
   puts "ragu " +"pattabi"
   puts "ragu " + " pattabi"

Сколько сложить...

hr = my_intf->do_the_thing_with( i_1,
                                 i_2,
                                 i_3 );

hr = my_intf->do_the_thing_with( "enter_the_dragon", 1965,
                                 "return_of_the_dragon", 1972 );

hr = my_intf->do_the_thing_with( "enter_the_dragon", "bruce lee", "chinese" );

Мне приходилось "принимать такие решения, когда я кодирую. Это помогает в основном, но мой ум не позволит мне двигаться дальше, не получив права. Я восстанавливаю: -)

Ответ 13

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

И всегда есть комментарии.

Ответ 14

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

Ответ 15

Я не вижу смысла в вашем примере css... У Стив есть более читаемый пример.

Что касается утверждений if - я не вижу никаких рифм или причин для того, чтобы положить самое тяжелое на дно. Обычно я обычно ставил более часто ожидаемую ситуацию.

Ответ 16

Ваш пример должен быть:

#divPreview {
    width: 210px;
    height: 128px;
    border: #779 1px solid;
    overflow: auto;
    text-align: center;
    vertical-align: middle;
    background-color: #fff";
}

Следуя ширине имени, а не ширине всей линии.;)

Но, да, ты сумасшедший.: P

Ответ 17

Код должен быть стилизован, чтобы быть читаемым, поддерживаемым и последовательным. Лично я считаю, что код с произвольным интервалом трудно читать. Зачем читателю сканировать код по экрану/странице, чтобы собрать фрагменты инструкции? Порядок блоков кода в заявлении должен располагаться в порядке логики, удобочитаемости и иногда корректироваться для оптимизации. Ненужное смещение вещей - пустая трата времени и делает код сложнее читать, а не проще. Кто-нибудь не читал Макконнелла?

Ответ 18

В некотором смысле я. Но я больше склоняюсь к минимуму. Css - это, безусловно, мой пример. Слишком много времени для добавления здесь, но в основном, я буквенно-буквенный порядок.

Почему?

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

Это может быть nano секунд для вас всех, но это избавляет меня от разочарования и времени, потерянного позже.

Ответ 19

Алфавитный порядок лучше масштабируется; его преимущество в сложном файле CSS намного больше, чем в небольшом файле.

Ответ 20

Я тоже страдаю от OCD, когда дело доходит до кода. Я со Стивом, табуируя твои свойства, это путь.

var myObj = {
    anInt: 3993,
    aFunction: function() {alert('woot');},
    aString: "Random",
    aBool: false
}

Это немного больно. Некоторым может это не понравиться, но это заставляет меня чувствовать себя намного лучше:

var myObj = {
    anInt:      3993,
    aBool:      false,
    aString:    "Random",

    aFunction:  function() {
                    alert('woot');
                }
}

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

Ответ 21

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

Однако некоторые ваши особенности не будут оптимизированы. Например, если вы должны были организовать случаи в инструкции switch в соответствии с количеством утверждений в случае, вы не сможете оптимизировать его, поставив более вероятные случаи в верхней части.

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

Ответ 22

Как правило, нет никакого вреда в том, чтобы заставить его выглядеть "красивым", но, как и в большинстве случаев, используйте умеренность. Например, я бы предпочел сохранять элементы в одном порядке каждый раз с группой похожих элементов вместе вместо их сортировки. Выравнивание операторов и значений в порядке, но не изменяйте порядок.

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

Ответ 23

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

Ответ 24

Я предпочитаю держать стиль форматирования простым. Отступ по блокам и порядок по логике/оптимизации. Я использую форматирование среды IDE (по крайней мере, в Visual Studio, Eclipse и Netbeans). С CSS, однако, одна строка для каждого стиля с отступом детей:

#header {}
  #header h1 {}
  #header h2 {}

#nav {}
  #nav ul {}
  #nav li {}
    #nav li a {}
    #nav li a:hover {}

#content {}
  #content p {}

#footer {}

class A {

  private int b = 3;
  private int c = 2;

  public void method(string str) {

     if(str != null && str.length > 5) 
         DoStuffWithString();
     else 
         ShowInvalidError();

  }
}

Ответ 25

Довольно для меня читабельна.

       int anInt    = 10;
     float aFloat   = 1.2155;
MyOwnClass myObject = null;

выглядит красиво, но это боль, чтобы прочитать такой код после некоторого времени. И добавление новых переменных - боль в этом случае.

Я останавливаюсь на

int anInteger = 10;
float aFloat = 1.2155;
MyOwnClass myObject = null;

Мои навязчивые идеи: пространство до и после операторов сравнения и новая строка перед открывающей скобкой (странно, почему люди не используют этот способ и предпочитают подход с открытием-скобки на одном уровне).

Ответ 26

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

Я вырезал и вставлял фрагмент из меня в полной одержимости:

public static String intArrayToString( final int[] array ) {

    if ( array.length == 0 ) {

        return "[]" ;
    }

    StringBuffer sb = new StringBuffer() ;

    sb.append( "[ " ).append( array[ 0 ] ) ;

    if ( array.length > 1 ) {

        for ( int i = 1 ; i < array.length ; i++ ) {

            sb.append( ", " ).append( array[ i ] ) ;
        }
    }
    return sb.append( " ]" ).toString() ;
}

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

Я надеюсь, что ваша вторая примерная форма является нормой, меня учили в университетстве писать эти сравнения, как если бы они были на линии:

if ( 0 < n && n < 10 ) {

    doSomething() ;
}

А что касается последнего примера, я бы опустил логическое сравнение. Истинным случаем, тогда false:

if ( afflicted ) {

    doSomething() ;

} else {

    doSomethingElse() ;
}

Ответ 27

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

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

Любой человек может написать код, который выглядит сложным. Но разработчик требует отличного кода и превращает его во что-то, что все указывают на него и говорят, о да, что легко и просто понять.

Ответ 28

Единственное, что я могу изменить на исходном посту, было бы условным. Я не считаю условным предпочтение стиля, а скорее логичным. Наиболее распространенным случаем был бы первый случай, и он достиг бы наименее распространенного случая. Применяется к операторам if и операторам switch в моем коде.

Ответ 29

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

Более важным моментом является то, что код, написанный человеком, предназначен для чтения человеком. Поэтому постарайтесь сделать его максимально читаемым. Если дополнительные штрихи могут прояснить ваш код, сделайте это. В любом случае большинство пробелов используются для удобочитаемости. Например, отступы чисто эстетичны - это большинство языков.

Ответ 30

Мне нравится следить за тем, чтобы между строк кода было достаточное расстояние, и у меня есть комментарии, которые объясняют вещи. Это о степени моего убирания.

В Visual Studio я использую Ctrl + K, затем Ctrl + D (код автоформата) разумно, чтобы все было правильно выровнено/разнесено. Я не как OCD, как вы, хотя:)