Что лучший способ состоит в том, чтобы использовать пробел при программировании? [закрытый]

Держите свои дифференциалы в чистоте.

Делайте все, что хотите, с пробелами со следующими ограничениями:

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

Почему?

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

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

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

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

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

public void MyMethod( int param1, double param2 ) {
    if ( param1 < param 2 ) {
        member.OtherMethod( param1 );
    }
}

... но на самом деле, каждому свое. :)

Кроме того, если вы используете Visual Studio или другой инструмент, который его поддерживает, потратьте время на настройку правил автоматического форматирования и неукоснительно используйте автоформатирование. :) Это действительно поможет сохранить ваш код чистым и последовательным.

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

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

Некоторые рекомендации, чтобы узнать, как другие программисты используют белые соки (из мира Java):

• прочтите «руководство по стилю» (например, Элементы стиля Java
• прочтите хорошо известные примеры кода ( например, JDK содержит исходный код для всех неродных классов JRE)
• посмотрите, что поддерживают ваши инструменты (Eclipse имеет функцию «автоматического форматирования», Ctrl + Shift + F); просто позвольте инструменту сделать отступ в вашем коде !

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

В общем, и это субъективно...

Открытые и закрытые фигурные скобки (например, { и }) идут в строке сами по себе. (Исключение для javascript, где открытая фигурная скобка ставится в строке, создающей блок)

Оставляйте пустую строку между методами.

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

Это не совсем проблема пробельных символов, но объявляйте только одну переменную в строке. Не складывайте переменные в стек в объявлениях.

int i, j;  // stacked declaration - don't do this!

Также не складывайте несколько утверждений в одну строку.

Делайте отступы легко читаемыми; обычно достаточно 4 пробелов.

Длина строки должна быть достаточно короткой, чтобы поместиться на мониторе. Разделяйте длинные строки кода, а продолжения отступайте.

Если список параметров слишком длинный для одной строки, отформатируйте его по одному параметру на строку.

Это должно помочь вам начать.

Будьте последовательны, даже при изменении кода других разработчиков. Если стандарты отступов (если таковые имеются) вашего проекта не предписывают, как форматировать код, или вы не используете автоматический инструмент, такой как Narrange или Resharper , то попробуйте придерживаться форматирования, используемого другим разработчиком. Да, при необходимости включите индикаторы пробелов (для обсуждения табуляции и пробелов)

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

Настоящая читабельность обеспечивается модульным самодокументированным кодом. Это вытекает из согласованности, интеллектуального наименования полей и функций и принципов проектирования (особенно разделения задач). Эти вещи меня впечатлят. Для пробелов у меня есть средства автоматического форматирования.

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

Я рекомендую вам прочитать Code Complete и Clean Code. Эти книги научат вас форматированию кода, комментированию и многим другим темам.

Существует множество стилей или правил кодирования. Думаю, никого не впечатлит макет или интервал, и он не обратит больше внимания на сам код. Инструменты могут преобразовывать один стиль кодирования в другой (средство улучшения кода), так что вы можете довольно безопасно выбирать любой стиль. Как сказал jjnguy, самое главное - быть последовательным.

То, с чем согласны почти все:

• Ставьте пробелы после запятых
• Ставьте новые строки после точки с запятой (за исключением для объявлений циклов)
• Отступ тело всех блоков (что-либо внутри {} ) одной табуляцией или четырьмя пробелами (на ваш выбор)
• Поместите новую строку после закрывающего } , который завершает блок (с несколько исключений)

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

Есть два основных способа справиться с if блоками и чем-либо с одинаковым форматом ( для , , а , с использованием , и т. д.):

if (condition) {
    /* code */
}

против:

if (condition)
{
    /* code */
}

Это чисто вопрос предпочтений. Выберите один стиль и придерживайтесь его (или придерживайтесь стиля остальной команды).

Одно возможное исключение из правила «новой строки после } » - для сгруппированных if / else if / else , блоков, блоков try / catch или другие тесно связанные блоки, которые многие предпочитают размещать следующим образом:

if (condition) {
    /* code */
} else if (condition2) {
    /* code */
} else {
    /* code */
}

Самым важным является то, что

1. Доступно для чтения вам
2. Доступно для чтения другим, работающим над проектом

У каждого будут свои нюансы. Если ваш начальник говорит, что вы должны использовать вкладки, вы должны использовать вкладки. Если в соответствии с соглашением компании 4 пробела в скомпилированном коде и 2 в файлах метаданных, это то, что вы делаете.

Но будьте последовательны и убедитесь, что это читаемо. Читаемость - единственный важный критерий.

Некоторые вещи, которые нужно сделать: Обязательно поищите на Stack Overflow больше примеров с похожими тегами.

Как выглядит код хорошего программиста?

https://stackoverflow.com/questions/563036/what-is-elegant-code

То, что НЕ нужно делать:

https://stackoverflow.com/questions/237719/most-frustrating-programming-style-youve-encountered