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

Решение сводится к следующему:

<style>
.rowon {
 background-color:#dedede;
}

.rowoff{

}
</style>

В шаблоне:

<#list items as item>
    <tr  class="<#if item_index % 2 ==0>rowon<#else>rowoff</#if>"><td>${item}</td></tr>
</#list>

Однако, как указано в предыдущем ответе, это можно сделать с CSS, без этого решения freemarker (см. http://www.w3.org/Style/Examples/007/evenodd ):

<style>
.striped tr:nth-child(odd) {background: #eee}
.striped tr:nth-child(even) {background: #fefefe}
</style>

А затем просто использовать обычную таблицу без классов на строках:

<table class="striped">
 <tr><td>hello</td></tr>
 <tr><td>hello</td></tr>
 <tr><td>hello</td></tr>
 <tr><td>hello</td></tr>
</table>

ИЛИ с freemarker сгенерированной таблицы:

<table class="striped">
<#list items as item>
    <tr><td>${item}</td></tr>
</#list>
</table>

Так что это

Флаг СРОЧНЫЙ можно установить с помощью send () с установленным флагом MSG _ OOB . Как следует из этого, передаваемые данные являются внеполосными, что означает, что они обычно не принимаются вызывающей стороной, просто вызывающей read () . Приемная сторона получает некоторую индикацию данных OOB, например, сигнал SIGURG , или разъем становится исключительным и может быть проверен с помощью select () .

Чаще всего вы не хотите устанавливать флаг СРОЧНЫЙ.

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

Один из них, на который я смотрел на днях, стоит около 35 000 долларов США 1, 1000 долларов США для лицензии сайта. Это куриный корм. Ты, наверное, тратишь больше, чем на туалетную бумагу.

Запустите модуль переформатирования в рамках процедуры проверки исходного кода и не беспокойтесь об этом.

Может быть, вы могли бы иметь что-то вроде getView () в документе , переопределяя его в каждой реализации?

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

Представьте, что на более позднем этапе добавляется новый тип Документ (например, Электронная таблица ). Требуется только добавить объект Электронная таблица (наследующий от Документ ), чтобы все работало. Следовательно, Электронная таблица должна обеспечивать возможность отображения самой себя.

Возможно, он может сделать это автономно. Например,

new Spreadsheet().display();

Возможно, он может сделать это в сочетании с представлением, например, механизмом двойной отправки

new Spreadsheet().display(view);

. В любом случае электронная таблица/письмо/электронная почта будет внедрять этот метод view () и отвечать за дисплей. Ваши объекты должны говорить на каком-то видовом агностическом языке. например, в документе написано «отобразить это полужирным шрифтом». Затем представление может интерпретировать его в соответствии с его типом. Должен ли ваш объект знать о представлении? Возможно, ей нужно знать возможности, которыми обладает эта точка зрения, но она должна уметь говорить таким агностическим образом, не зная деталей точки зрения.

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

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

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

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

Вы можете использовать опцию форматирования кода в eclipse, если важно читать код, отформатированный иначе, чем вы привыкли.

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

К счастью, гораздо проще составить набор стандартов для именования.

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

Существует стандарт для PHP?

(Cue понижает количество)

Я согласен с тем, что должны быть стандарты. Я выбрал определенный набор параметров автоматического форматирования в Visual Studio 2008, и все остальные разработчики импортировали эти параметры настройки.

Среди проблем, с которыми можно легко столкнуться с различными стилями, - печально известные места и вкладки. В VS 2008 иногда возникает ситуация, когда смешанные стили отступов и нажатие Ctrl-E, D для форматирования всего документа могут привести к сбою VS.

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

Изменить: Что касается широты, у меня есть некоторые рекомендации для моих разработчиков относительно правил именования и удобочитаемости, но не строгие правила, кроме форматирования (какая линия фигурной скобки продолжается и так далее). Я бы не возражал, если бы один из них поставил частные поля внизу или наверху. Если бы я добавил новый, я бы подражал.

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

Да, они должны соответствовать стандарту. В противном случае это беспорядок.

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

Во-первых, раз уж вы заговорили о венгерской нотации, вот обязательная ссылка на статью Joel's Making Wrong Code Look Wrong. :-) В ней обсуждается использование венгерского языка в том, что Джоэл считает хорошим и плохим способами.

В принципе, я согласен, что групповой стандарт - это хорошо. На практике, мой опыт показывает, что с ними трудно договориться - например, один человек будет религиозно относиться к открывающим паренсам в конце строки, а другой будет так же религиозно относиться к тому, чтобы они были в строке сами по себе. Их также трудно обеспечить, особенно если нет обзоров кода или других механизмов, позволяющих убедиться, что код соответствует стандарту. Я бы сказал, что нужно стремиться к тому, что лучше работает; например, в моем предыдущем примере любой из методов кажется достаточно читабельным, так что, возможно, это можно оставить, но если вы используете соглашение об именовании переменных, не опускайте руки, когда кто-то пытается использовать 'a' для переменной, содержащей имя клиента!

Стандарты кодирования или любой другой тип процесса не заменяют навык. Если ваша команда опытна и выполняет свою работу (и под словом «сделано» я также имею в виду, что то, что они производят, можно поддерживать), то стандарты кодирования на самом деле никуда вас не приведут.

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

редактировать, чтобы отразить OP править

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

для (int i = 0; i