Я довольно новичок в программировании и учебе, я видел разные способы форматирования кода, комментариев и т. Д .; и были рекомендованы по разным методикам.Каков наилучший способ использования пробелов во время программирования?
Я в основном программирую на C#, C++ и Java, поэтому я хочу знать, что является лучшим способом для кода макета, так что если другим людям, где можно пройти, они будут впечатлены тем, насколько просто и легко понять это.
Лучшее правило следовать: (и, вероятно, единственное правило, все согласятся на)
Будьте последовательны!
Выберите один стиль и придерживайтесь его. Всегда размещайте фигурные скобки в одном и том же месте. Используйте аналогичные соглашения об именах. Не смешивайте язычки и пробелы и т. Д.
Это сказано. Также, как правило, неплохо попытаться следовать конвенциям, которые уже существуют для языка.
При работе в команде с людьми, убедитесь, что вы все согласны на стиль и придерживаться его. Если вы этого не сделаете, часто один разработчик переформатирует файл с помощью своего автоматического форматирования, а затем вы можете иметь сотни небольших конфликтов, которые были вызваны просто пробелами.
Хороший ответ. Я попытался предположить, что в моем комментарии, но я не думал, что моя версия была достаточно хорошей, чтобы быть ответом. – MJB
@ MJB Я готов поспорить, что это единственный «правильный» ответ. Никто никогда не согласится на стиль 100%. Но люди согласятся, что вы всегда должны быть последовательными. – jjnguy
Некоторые вещи достаточно объективны. Например, большинство людей согласны с тем, что файлы Java должны содержать разрывы строк и не быть целым файлом в одной строке. И если вы согласны с этим и объективно оправдываете это, то, вероятно, есть еще много вещей, которые вы можете оправдать, объективно. Такие как отступы (используя его, а не используя его). Но +1, поскольку согласованность является самым важным фактором. –
Наиболее важные вещи, которые
Каждый будет иметь свои нюансы. Если ваш босс говорит вам, что нужно использовать вкладки, то вы используете вкладки. Если соглашение компании составляет 4 пробела на скомпилированном коде и 2 в файлах метаданных, это то, что вы делаете.
Но будьте последовательны и убедитесь, что они читаемы. Считываемость является единственным существенным критерием.
Thing почти все согласятся на:
for петель){}) на одной вкладке или в четырех пробелах (по вашему выбору)}, которая заканчивает блок (за некоторыми исключениями)Есть намного больше вещей, чем некоторые команды будут настаивать на согласованности, но эти элементы форматирования кода являются универсальными.
Есть два основных способа решения if блоков и что-нибудь в том же формате (for, while, using и т.д.):
if (condition) {
/* code */
}
против:
if (condition)
{
/* code */
}
Это чисто вопрос предпочтения. Выберите один стиль и придерживайтесь его (или совместите с остальной частью вашей команды).
Одно возможное исключение из правила «новой строки после }» для сгруппированных if/else if/else, блоки, try/catch блоки или другие тесно связанные блоки, которые многие люди предпочитают пространство таким образом:
if (condition) {
/* code */
} else if (condition2) {
/* code */
} else {
/* code */
}
Я бы не сказал пробелы после того, как запятые универсальны. Я знаю много людей, которые их ненавидят ... – Kendrick
Кроме того, этот: «Положите новую строку после закрытия'} '« Я не могу согласиться с этим 100% времени. – jjnguy
@ Kendrick, эти люди должны быть избиты ключом. (Я никогда не встречал никого, кто избегал пробелов после запятых). –
Есть много стилей или правил кодирования. Я думаю, никто не будет впечатлен макетом или интервалом и больше внимания уделяет самому коду. Инструменты могут конвертировать из одного стиля кодирования в другой (код beautifier), чтобы вы могли спокойно выбирать любой стиль. Как сказал jjnguy, самое главное - быть последовательным.
whitespace programming language. Язык, который имеет только пробелы
Всегда есть кто-то в толпе. – kenny
Это довольно спорная (и субъективная) тема, поэтому не будет «правильного» ответа. Тем не менее, мой совет - использовать вертикальные пробелы экономно, так как слишком большая его часть уменьшает количество кода, которое можно увидеть на экране в данный момент времени.
Я лично хотел бы использовать горизонтальный пробел, чтобы сделать код более читаемым, как так:
public void MyMethod(int param1, double param2) {
if (param1 < param 2) {
member.OtherMethod(param1);
}
}
... но на самом деле, для каждого его/ее собственной. :)
Кроме того, если вы используете Visual Studio или другой инструмент, который его поддерживает, потратьте время на настройку правил автоматического форматирования и религиозно используйте автоформат. :) Это действительно поможет сохранить ваш код чистым и последовательным.
Лично Я бы сказал, наоборот, используйте вертикальные пробелы, когда вам нужно очертить логический абзац или группировку, но я согласен - не помещайте столько кода в метод, который вы заканчиваете тем, что уходил с экрана для большинства методов. t discard readability for code-cramming, только код лучше. –
Я использую пустые строки для разделения логических блоков в пределах одного и того же объема, поэтому я согласен с этим. Помещение открывающих фигурных скобок на той же строке, что и блок, дает мне дополнительное пространство для работы, однако – devios1
В общем, пробел - ваш друг. Добавьте его, если он сделает код более читаемым. Пробелы сводятся к наиболее эффективному коду: нет!
В целом, и это субъективно ...
Открытие и закрытие фигурные скобки (например, {и}) перейти на линии сами по себе. (Исключение для javascript, где открытая фигурная скобка идет по линии, которая создает блок.)
Оставьте пустую строку между методами.
Если это помогает читаемости, оставьте пустую строку между свойствами.
Это не просто проблема с пробелами, а только объявление одной переменной в строке. Не ставьте переменные в объявлениях.
int i, j; // stacked declaration - don't do this!
Не складывайте несколько операторов на одной строке.
Держите ваши углубления легко читаемыми; обычно 4 пробела хороши.
Держите длину линии достаточно короткой, чтобы она соответствовала вашему монитору. Разделите длинные строки кода и продолжения отступа.
Если список параметров слишком длинный для одной строки, отформатируйте его по одному параметру на строку.
Это должно вас начать.
Будьте единообразны даже при изменении кода других разработчиков. Если стандарты отступов (если они есть) вашего проекта не предписывают, как отформатировать ваш код, или вы не используете автоматический инструмент, например Narrange, или Resharper, тогда попробуйте придерживаться форматирования, используемого другим разработчиком. Да, включите индикаторы пробела, если вам нужно (для обсуждения дебатов и пробелов)
Пробел не является основным фактором при создании считываемого кода. В самом деле, я никогда не буду «впечатлен тем, насколько простым и легким это понять» из-за использования автором пробелов. Я мог бы пойти другим путем и подумать, что какой-то код очень нечитабелен из-за плохого использования пробелов, но в лучшем случае вы заставите меня не разочароваться в вас.
Настоящая читаемость обеспечивается модульным, документирующим кодом. Он вытекает из последовательности, интеллектуального наименования полей и функций и принципов проектирования (особенно разделяя проблемы). Все это произведет на меня впечатление. Для пробелов у меня есть автоформаты.
Что касается предложений по передовым методам с пробелами, я думаю, что в других ответах есть все хорошие моменты.
Я рекомендую вам прочитать Код Завершить и Очистить код. Эти книги расскажут вам о форматировании кода, комментировании и многом другом.
Держите ваши различия в чистоте.
делать все, что вам нравится с пробелами при следующих ограничениях:
Почему?
Важнейшим фактором при работе с пробелами является не читаемость самих файлов, а читаемость различий. Различия - это то, что вы будете смотреть, когда холодный пот стекает по вашему позвоночнику, и мышление кажется более трудным, чем обычно.
В приведенных выше двух правилах убедитесь, что разницы являются чистыми и читаемыми. Быть последовательным в том, как вы справляетесь с пробелами, помогает, но он защищен только в идеальном мире. Это хорошая вещь, к которой нужно стремиться, но не так важна, как сохранение различий в чистоте.
В качестве оптимизации вы можете попытаться согласовать код стиля с другими, чтобы не тратить время на соблюдение 1 и 2.
Это хороший момент, и я несколько раз нарушал №1. Обычно это было вызвано большой болью позже. –
Некоторые вещи, чтобы сделать: Убедитесь, что искать переполнения стека для большего количества примеров со схожим теги.
What does a good programmer's code look like?
https://stackoverflow.com/questions/563036/what-is-elegant-code
Материал не делать:
https://stackoverflow.com/questions/237719/most-frustrating-programming-style-youve-encountered
Там нет "лучше всего" форматирование, но если вы используете один и тот же форматирование, как и большинство других программистов, его легче чтобы они могли прочитать ваш код, и вам будет легче читать их код!
Некоторые руководящие принципы, чтобы узнать, как другие программисты используют белые sapces (от Java мира):
Пытался добавить «субъективный» тег, но не может из-за 5 тегов. Однако не то, что ответы будут несколько субъективными! –
Существует ровно n "BEST" способов сделать это, где n - количество людей, которых вы просите. Я полагаю, вы получите здесь несколько замечательных предложений; выберите тот, который вам больше всего нравится, и придерживайтесь его. Последовательность упрощает чтение, но никогда не будет впечатлять будущих программистов. С другой стороны, если вы измените средний модуль использования пробелов, те будущие программисты, которые приходят, чтобы исправить ваш код, будут вас ненавидеть. – MJB
Попробуйте 'whitespace' для программирования. Здорово. – aviraldg