Вы думаете, что компания-разработчик программного обеспечения должна наложить разработчиков стиль кодирования? [закрытый]
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
28 ответов
Я думаю , команда (а не компания ) должна договориться о ряде инструкций для довольно последовательного стиля. Это делает это более простым для обслуживания.
, Как глубоко? Столь мелкий, как можно договориться. Чем короче и более ясный это, тем более вероятно случается так, что все члены команды могут согласиться на него и будут соблюдать его.
Мне нравится ответ Ilya, потому что он включает важность удобочитаемости и использование непрерывной интеграции как механизм осуществления. Hibri упомянул FxCop, и я думаю его использование в процессе сборки как один из критериев определения, передает ли сборка, или сбои были бы более гибкими и эффективными, чем простое документирование стандарта.
Я полностью соглашаюсь, что кодирование стандартов должно быть применено, и что это должно почти всегда быть на уровне команды. Однако существует несколько исключений.
, Если команда является написанием кода, которое должно использоваться другими командами (и здесь я подразумеваю, что другие команды должны будут посмотреть на источник, не только, используют его в качестве библиотеки), затем существуют преимущества для создания единых стандартов через все команды, использующие его. Так же, если политика компании состоит в том, чтобы часто перемещать программистов от одной команды другому или в состоянии, где одна команда часто хочет снова использовать код от другой команды затем, вероятно, лучше наложить стандарты по всей компании.
Кодирование стандартов: ДА. По причинам, уже покрытым этим потоком.
стандарты Моделирования: НЕТ. Ваше читаемое, мой озадачивающий спам, и наоборот. Хороший комментарий и факторинг кода обладают намного большим преимуществом. Также отступ гну.
Каждая компания должна. Последовательный стиль кодирования удостоверяется выше readibility и пригодность для обслуживания кодовой базы через целое Ваша команда.
магазин, в котором я работаю, не имеет объединенного стандарта кодирования, и я могу сказать, что мы (как команда) значительно страдаем от этого. Когда существует, не будет от людей (как в случае некоторых моих коллег), руководитель группы должен ударить по кулаку на таблице и наложить некоторую форму стандартизированных инструкций по кодированию.
Когда-либо язык имеет общие стандарты, которые используются сообществом. Необходимо следовать за ними, а также возможный так, чтобы код мог сохраняться другими людьми, привыкшими к языку, но нет никакой потребности быть диктаторским об этом.
создание официального стандарта является неправильным, потому что компания, кодирующая стандарт, обычно слишком тверда, и не может течь с общим сообществом, использующим язык.
, Если у Вас есть проблема с членом команды действительно быть там в стиле кодирования, это - превосходная вещь для группы мягко предложить, не хорошая идея в обзоре кода.
Да с точки зрения использования общего стандарта именования, а также общего расположения классов и кода позади файлов. Все остальное открыто.
Современные IDE позволяют Вам определить шаблон форматирования. Если существует корпоративный стандарт, то разработайте конфигурационный файл, который определяет все форматирование, оценивает Вас забота о, и удостоверьтесь, что все выполняют средство форматирования, прежде чем они зарегистрируются в своем коде. Если Вы хотите быть еще более строгими об этом, Вы могли бы добавить рычаг фиксации, чтобы Ваша система управления версиями форматировала код, прежде чем это будет принято.
Мое мнение:
- Некоторые основные правила хороши, поскольку это помогает всем прочитать и поддержать код
- , Слишком много правил плохи, поскольку это останавливает разработчиков, вводящих новшества с более ясными способами разметить код
- , Отдельный стиль может быть полезен определить историю файла кода. Инструменты разности/вины могут использоваться, но подсказка все еще полезна
Я согласился бы, что непротиворечивость является ключевой. Вы не можете полагаться на симпатичную печать IDE для спасания положение, потому что некоторым разработчикам не может понравиться использовать IDE, и потому что, когда Вы тралите через кодовую базу тысяч исходных файлов, к структурной распечатке программы все файлы просто не выполнимо, когда Вы начинаете работать над ними и выполняете откат впоследствии, таким образом, Ваш VCS не пытается фиксировать назад все изменения (забивающий репозиторий с бесполезными обновлениями, которые обременяют всех).
я предложил бы стандартизировать, по крайней мере, следующее (в порядке убывания важный):
- Пробел (является самым легким при выборе стиля, который соответствует автоматической симпатичной печати некоторого общего инструмента)
- Именование (файлы и папки, классы, функции, переменные...)
- Комментарий (использующий формат, который позволяет автоматическое поколение документации)
Да.
стандарты Кодирования являются распространенным способом гарантировать, что код в определенной организации будет следовать за Принципом Наименьшего количества Удивления: непротиворечивость в стандартах, запускающихся от именования переменной до добавления отступа к изогнутому использованию фигурной скобки.
Кодеры, имеющие их собственные стили и их собственные стандарты, только произведут кодовую базу, которая непоследовательна, сбивает с толку, и разбивающий для чтения, особенно на больших проектах.
Эти стандарты кодирования для компании, на которую я раньше работал. Они четко определены, и, в то время как это взяло меня некоторое время для привыкания им, означал, что код был читаем всеми нами и универсальной формой полностью через.
я действительно думаю, кодируя стандарты, важны в компании, если ни один не установлен, там будут столкновениями между разработчиками и проблемами с удобочитаемостью.
Наличие универсальной формы кода полностью через подарки лучший код конечному пользователю (таким образом, выглядит, как будто это записано одним человеком - который с точки зрения Конечных пользователей это должно - что человек, являющийся "компанией" и это также помогает с удобочитаемостью в команде...
Общий стиль кодирования способствует непротиворечивости и помогает различным людям легко понять, поддержать и развернуть целую кодовую базу, не только их собственные части. Это также помогает новым людям изучить код быстрее. Таким образом у любой команды должны быть инструкции по тому, как код, как ожидают, будет написан.
Важные инструкции включают (без определенного порядка):
- пробел и добавление отступа
- стандартные комментарии - файл, класс или заголовки метода
- соглашение о присвоении имен - классы, интерфейсы, переменные, пространства имен, файлы
- аннотации кода
- организация проекта - структуры папок, двоичные файлы
- стандартные библиотеки - что шаблоны, дженерики, контейнеры и так далее для использования
- обработка ошибок - исключения, hresults, коды ошибок
- поточная обработка и синхронизация
Кроме того, опасайтесь программистов, которые не могут или не адаптироваться к стилю команды, неважно, насколько яркий они могли бы быть. Если они не будут играть по одному из правил команды, то они, вероятно, не будут играть по другим правилам команды также.
Да, я думаю, что компании должны. Разработчик, возможно, должен привыкнуть к стилю кодирования, но по-моему хороший программист должен быть в состоянии работать с любым стилем кодирования. Поскольку Midhat сказал: важно иметь последовательную кодовую базу.
я думаю, что это также важно для проектов с открытым исходным кодом, нет никакого супервизора, чтобы сказать Вам, как написать Ваш код, но много языков имеют спецификации о том, как именование и организация Вашего кода должно быть. Это помогает много при интеграции компонентов с открытым исходным кодом в проект.
Инструкции по стилю чрезвычайно важны, являются ли они для дизайна или разработки, потому что они ускоряют коммуникацию и производительность людей, которые работают совместно (или даже один, последовательно, беря части старого проекта). Не наличие системы конвенции в компании просто просит, чтобы люди были так непроизводительны, как они могут. Большинство проектов требует сотрудничества и даже тех, которые не делают может быть уязвимо для нашего естественного требования осуществить наши прерывания программирования и держать в курсе. Наше требование учиться мешает нашей непротиворечивости - который является хорошей вещью в и себя, но может управлять новым сотрудником сумасшедшая попытка изучить системы, на которых они вскакивают.
Как любая другая система это предназначено окончательно и не злое, действительная мощность руководства находится в руках ее людей. Сами разработчики определят то, что существенные и полезные части и затем, надо надеяться, используйте их.
Как закон. Или английский язык.
Руководства по стилю должны быть настолько глубокими, как они хотят быть - если это подходит на сессии мозгового штурма, это должно быть включено. Это нечетно, как Вы сформулировали вопрос потому что в конце дня нет никакого способа "наложить" руководство по стилю, потому что это - только РУКОВОДСТВО.
прочитайте руководство, затем подберите хороший материал и продолжите его.
Несомненно, инструкции хороши, и если это не плохо использовало Венгерская запись (ха!), это, вероятно, улучшит непротиворечивость и сделает чужой код чтения легче. Инструкции должны просто быть инструкциями, хотя, не строгие правила осуществили на программистах. Вы могли сказать мне, куда поместить мои фигурные скобки или не использовать имена как временный файл, но что Вы не можете сделать, вынуждают меня иметь пробелы вокруг индексных значений в скобках массива (они попробовали однажды...)
Как другие упомянули, я думаю, что это должно быть разработкой или командой - компания (т.е. подразделения) не должна быть вовлечена в такое решение.
, Но еще одна вещь я добавил бы, любые правила, которые реализованы, должен быть осуществлен инструментами и не людьми. Худший вариант развития событий, IMO, является некоторым фанатичным снобом грамматики (да, мы существуем; я знаю, потому что мы можем пахнуть, наше собственное) пишет некоторую документацию, обрисовывающую в общих чертах ряд инструкций по кодированию, которые абсолютно никто на самом деле не читает или следует. Они становятся устаревшими со временем, и поскольку новые люди добавляются к команде, и старики уезжают, они просто становятся устаревшими.
Затем некоторый конфликт возникает, и кто-то помещается в неудобное положение необходимости противостоять кому-то еще о стиле кодирования - этот вид конфронтации должен быть сделан инструментами а не людьми. Короче говоря, этот метод осуществления наименее желателен, по-моему, потому что это слишком легко проигнорировать и просто просит программистов спорить о глупых вещах.
более оптимальному варианту А (снова, IMO) состоял в том, чтобы бросить предупреждения во время компиляции (или что-то подобное), пока Ваша среда сборки поддерживает это. Не трудно настроить это в VS.NET, но я не знаю о других средах разработки, которые имеют подобные функции.
Существует много серьезных оснований для стандартов для определения способа, которым приложения разрабатываются и способ, которым должен быть похожим код. Например, когда все используют тот же стандарт, автоматическая программа проверки стиля могла использоваться в качестве части CI проекта. Используя те же стандарты улучшают удобочитаемость кода, и помогает снизить напряженность между членами команды о рефакторинге того же кода по-разному. Поэтому:
- Весь код, разработанный конкретной командой, должен следовать точно тому же стандарту.
- Весь код, разработанный для конкретного проекта, должен следовать точно тому же стандарту.
- желательно, чтобы команды, принадлежащие той же компании, использовали тот же стандарт.
В компании по аутсорсингу исключение могло быть сделано для работы в команде для клиента, если клиент хочет осуществить собственный стандарт. В этом случае команда принимает стандарт клиента, который мог быть несовместимым с тем, используемым их компанией.
По-моему, я думаю, что это очень необходимо со стандартами и руководствами по стилю. Поскольку, когда Ваша кодовая база вырастет, Вы захотите иметь ее последовательный.
Как примечание стороны, именно поэтому я люблю Python; потому что это уже навязывает довольно много правлений о том, как структурировать Ваши приложения и такой. Сравните это с Perl, Ruby или безотносительно где у Вас есть экстремальная свобода (который не настолько хорош в этом случае).
Лучшее решение состояло бы в том, чтобы IDE рассматривали такое форматирование как метаданные. Например, вводное изогнутое положение фигурной скобки (текущая строка или следующая строка), добавление отступа и пробел вокруг операторов должно настраиваться, не изменяя исходный файл.
Я думаю, что программисты должны смочь адаптироваться к стилю других программистов. Если новый программист не может адаптироваться, который обычно означает, что новый программист слишком упрям для использования стиля компании. Было бы хорошо, если мы могли бы все сделать нашу собственную вещь; однако, если все мы кодируем вдоль некоторой инструкции по лубу, она делает отладку и обслуживание легче. Это только верно, если стандарт хорошо продуман и не слишком строгий.
Я полагаю, что наличие последовательной кодовой базы важно. Это увеличивает пригодность для обслуживания Вашего кода. Если все ожидают тот же вид кода, они могут легко считать и понять это.
Помимо этого не большая часть стычки, данной сегодняшние IDE и их возможности автоформатирования.
P.S.: у Меня есть эта раздражающая привычка к помещению моих фигурных скобок на следующей строке :). Никому больше, кажется, не нравится он
Я не полагаю, что у команды разработчиков должны быть инструкции по стилю, за которыми они должны следовать как правило. Существуют исключения, например использование <> по сравнению с "" в #include операторах , но эти исключения должен прибыть из необходимости.
наиболее распространенная причина я слышу, что люди используют для объяснения, почему инструкции по стилю необходимы, то, что код, написанный в общем стиле, легче поддержать тот код, написанный в отдельных стилях.Я не согласен. Профессиональный программист не собирается быть срываемым, когда они видят это:
for( int n = 0; n < 42; ++42 ) {
// blah
}
..., когда они привыкли видеть это:
for(int n = 0; n < 42; ++42 )
{
// blah
}
, Кроме того, я нашел, что на самом деле легче поддержать код в некоторых случаях, если можно идентифицировать программиста, который написал исходный код путем простого распознавания их стиля. Пойдите спрашивают их, почему они реализовали штуковину таким замысловатым способом за 10 минут вместо того, чтобы тратить лучшую часть дня, выяснив очень техническую причину, почему они сделали что-то неожиданное. Правда, программист должен был прокомментировать код, чтобы объяснить, что их обоснование, но в программистах реального мира часто не делают.
Наконец, если Joe требуются 10 минут, возвращаясь & при перемещении его фигурных скобок так, чтобы счет мог потратить 3 меньше секунд, смотря на код, он действительно экономил какое-либо время, чтобы заставить счет сделать что-то, что не прибывает естественное для него?
Да, но в причине.
Все современные IDE предлагают структурную распечатку программы кода одного нажатия клавиши, таким образом, точка "добавления отступа" довольно не важна, по-моему.
то, Что более важно, должно установить лучшие практики: например, используйте как можно меньше или "касательно" параметров... В этом примере у Вас есть 2 преимущества: улучшает удобочитаемость и также фиксирует много ошибок (много параметров является запахом кода и должно, вероятно, быть пересмотрено).
Выход за пределы то есть, по моему честному мнению, немного "анальному" и излишне раздражающему для devs.
<час>Положительная сторона Hamish Smith:
Стиль очень отличается от лучших практик. Это - позор, что 'кодирование стандартов' имеет тенденцию прокручивать два вместе. Если бы люди могли бы свести часть стиля к минимуму и сконцентрироваться на лучших практиках, которые, вероятно, добавили бы больше значения.
Вы думаете, что компания-разработчик программного обеспечения должна наложить разработчиков стиль кодирования?
Не нисходящим способом. Разработчики в компании-разработчике программного обеспечения должны договориться об общем стиле кодирования.
, Если да, как глубоко инструкции должны быть по Вашему мнению?
Они должны только описать различия от известных конвенций, пытаясь сохранить отклонение минимальным. Это легко для языков как Python или Java, несколько расплывчато для C/C++ и почти невозможно для Perl и Ruby.
, Например, добавление отступа кода должно быть включено?
Да, это делает код намного более читаемым. Сохраните добавление отступа последовательным с точки зрения пробелов по сравнению с вкладками и (если Вы выбираете пробелы), количество пробелов. Кроме того, договоритесь о поле (например, 76 символов или 120 символов) для длинных линий.
Компания должна наложить, что некоторый стиль должен сопровождаться. То, что разрабатывает, который является и как глубоко инструкции, должно быть решено коллективно сообществом разработчиков в компании.
я определенно установил бы инструкции по фигурным скобкам, добавлению отступа, назвав и т.д... Вы пишете код для удобочитаемости и пригодности для обслуживания. Всегда предполагайте, что кто-то еще собирается прочитать Ваш код. Существуют инструменты, которые будут автоматический волшебно форматировать Ваш код, и можно передать под мандат это, все используют инструмент.
, Если Вы находитесь на взгляде .NET stylecop, fxcop и Resharper
Вы хотите всех читающий и пишущий код стандартным способом. Существует два способа, которыми можно достигнуть этого:
- Клон единственный разработчик несколько раз и удостоверяется, что они все проходят то же обучение. Надо надеяться, они должны все быть в состоянии записать ту же кодовую базу.
- Дают Вашим существующим разработчикам явную инструкцию относительно того, чего Вы требуете. Вкладки или пробелы для добавления отступа. Где фигурные скобки находятся. Как прокомментировать. Инструкции по фиксации управления версиями.
, Чем больше Вы оставляете неопределенными, тем выше вероятность один из разработчиков столкнется на стиле.
Существует два типа соглашений.
Соглашения типа A: "пожалуйста, сделайте это, так будет лучше"
и тип B: "пожалуйста, езжайте по правой стороне дороги", в то время как ездить по другой стороне - это нормально, если все делают то же самое.
Нет такой вещи, как отдельная команда. Все коды в хорошей фирме как-то связаны, и стиль должен быть последовательным. Легче привыкнуть к одному новому стилю, чем к двадцати разным стилям .
Кроме того, новый разработчик должен уметь уважать практику существующей кодовой базы и следовать ей.