Comments 109
UFO just landed and posted this here
"_" не исключение, для приватных полей следует использовать this.variable синтаксис.
+2
это неправда. Во-первых, не путайте официальный гайдлайн с правилами хорошего тона. Устоявшихся традиций даже не две, а скорее три: с this, с underscore (_) и c m_. Последняя менее распространена, но ею, например, пользуется Рихтер.
Во-вторых, даже в официальном гайдлайне ничего не сказано о правилах именования приавтных полей. Пруф: msdn.microsoft.com/en-us/library/ms229012.aspx The naming guidelines for fields apply to static public and protected fields. You should not define public or protected instance fields.
Во-вторых, даже в официальном гайдлайне ничего не сказано о правилах именования приавтных полей. Пруф: msdn.microsoft.com/en-us/library/ms229012.aspx The naming guidelines for fields apply to static public and protected fields. You should not define public or protected instance fields.
0
SA1309: FieldNamesMustNotBeginWithUnderscore.
By default, StyleCop disallows the use of underscores, m_, etc., to mark local class fields, in favor of the ‘this.’ prefix.
Официальный гайдлайн не все читают, справедливости ради StyleCop тоже не все используют. Раньше сам писал m_, потом _, потом this. В Microsoft так-то бардак в исходных кодах привычное дело, так что проще положиться на инструмент который проверит и подскажет, чем на бумажный гайдлайн.
By default, StyleCop disallows the use of underscores, m_, etc., to mark local class fields, in favor of the ‘this.’ prefix.
Официальный гайдлайн не все читают, справедливости ради StyleCop тоже не все используют. Раньше сам писал m_, потом _, потом this. В Microsoft так-то бардак в исходных кодах привычное дело, так что проще положиться на инструмент который проверит и подскажет, чем на бумажный гайдлайн.
0
Угу, и имена методов с большой буквы в C#. Для и для имен булевых переменных, лично мне нравятся вопросительные предложения. Т.е. имя переменной не «done», а «isDone». Как то логичнее выглядит.
+2
job.isDone — вопросительное предложение?
-1
Во-первых, я говорил про переменные, а вы привели пример свойства/поля.
Во-вторых, да я считаю, что при чтении
if (job.IsDone)
лучше, чем
if (job.Done)
В-третьих, каждая команда вырабатывает свои соглашения, если вам больше нравится без Is, то это ваше право, просто надо всем придерживаться этого стиля и все…
Во-вторых, да я считаю, что при чтении
if (job.IsDone)
лучше, чем
if (job.Done)
В-третьих, каждая команда вырабатывает свои соглашения, если вам больше нравится без Is, то это ваше право, просто надо всем придерживаться этого стиля и все…
+1
В некоторых языках используется название именно «переменные объекта/класса», свойств/полей там нет. Но вообще я спросил, имея в виду, что в случае имени переменной/свойства/поля, то есть jobIsDone или job.isDone.isDone (сам такую форму предпочитаю) это утверждение, подразумевающее наличии какого-то объекта (не в смысле ООП, а в смысле существительного) могущее быть ложным или истинным, но не вопрос.
0
Немного в офтопик уйду: нравится, как это в ruby сделано, прямо в названии метода знак вопроса, исключительно хорошо.
0
Бесит "_" у приватных полей в C#.
+2
Не знаю как можно не следовать общему стилю. Если пишешь как-то по другому, то твой код выглядит как белая ворона, что лично меня до жути бесит… все должно быть красиво, перфекциониз (кажется это так называется).
+1
Не знаю как можно не следовать общему стилюОчень просто.
Когда проект большой, нужно сделать что-то небольшое, а времени знакомиться со всеми гайдлайнами проекта нет, то… вполне можно ляпнуть getJuneStat вместсо принятого getJunStat, при чем если рядом нет кода в котором написано getJunStat, то Вы просто не заметите, что Вы белая ворона:)
+2
Вы говорите верно, но иногда встречается код, из-за которого готов бросить программирование :)
А вообще, с книгой, ссылка на которую есть в конце топика, должен ознакомится каждый, особенно начинающий программист.
А вообще, с книгой, ссылка на которую есть в конце топика, должен ознакомится каждый, особенно начинающий программист.
+1
ИМХО С этой книгой обязан познакомиться каждый не начинающий программист. По крайней мере 1 — 2 года опыта программирования должно быть, хотя бы для того, чтобы понимать что в ней написано.
+2
UFO just landed and posted this here
«obj1, obj2» как говориться — «нет худшей причины назвать переменную $c, чем та, что $a и $b уже заняты»
+8
Ну на самом деле, многие так делают, и все правильно делают. Например, олимпиадное программирование, когда времени очень мало…
0
В олимпиадном программировании это не так критично на самом деле :) Много времени за компьютером тратится на обдумывание того — как писать, имена переменных по сравнению с этим тратят очень мало времени.
Ну и не стоит забывать, что IDE вполне сносно автодополняют имена переменных/методов/классов, а ими (IDE) на олимпиадах пользоваться не запрещено.
Ну и не стоит забывать, что IDE вполне сносно автодополняют имена переменных/методов/классов, а ими (IDE) на олимпиадах пользоваться не запрещено.
0
И, конечно же, не стоит забывать, что ваш код потом еще, возможно, придется читать сокоманднику, а он точно не обрадуется одно-двухсимвольным названиям переменных, если названия взяты наобум (w для ширины, h для высоты — логично, а вот «a» и «b» для того же — уже сложнее гораздо читать). В таком случае все сэкономленные секунды на написание коротких имен будут многократно съедены тем временем, которое ваш товарищ потратит на понимание кода — а вы ведь в это время, скорее всего, будете писать уже следующую задачу.
0
У всех есть скрипты, которые «просто должны работать и не важно что внутри», вот только внутри обычно такая жесть творится, что автор через месяц уже ничего не прочтет. Поэтому я обдумываю каждое название в коде — бывает долго, но иначе потом будет хуже.
А вообще, если вспомнить Дяду Боба, то в книге «Чистый код» он много и дотошно все моменты разбирает и объясняет что и почему.
А вообще, если вспомнить Дяду Боба, то в книге «Чистый код» он много и дотошно все моменты разбирает и объясняет что и почему.
0
Не критично, но юзают. А я и не говорил что время именно на кодирование уходит, пишут a, b, c, d… в том числе чтоб и не задумываться над названием. Ну и все-же кодируется так все быстрее, и аутокомплит тому не перечит.
Чтение сокомандником, происходит редко, и при наличии автора, который показывает и рассказывает.
Ну в общем, ваши аргументы, приняты частично). И как факт, таки многие так делают, и иногда все правильно делают.
Чтение сокомандником, происходит редко, и при наличии автора, который показывает и рассказывает.
Ну в общем, ваши аргументы, приняты частично). И как факт, таки многие так делают, и иногда все правильно делают.
0
Ну и помимо олимпиадного, нормальный пример для a, b, c:
Что явно лучше чем FirstVariableForSwaping / swapVar1 / tempVar и кучи всего другого.
procedure swap(var a : integer, var b : integer);
var c : integer;
begin
c := a;
a := b;
b := c;
end;
Что явно лучше чем FirstVariableForSwaping / swapVar1 / tempVar и кучи всего другого.
+3
arg1, arg2, temp
0
Мне кажется, что это не лучше чем a, b, c.
arg1, arg2 — не информативно, и так понятно что процедура принимает первый аргумент, второй аргумент…
temp — возможно и лучше, но если функция занимает 3 строки, и есть гарантия от самих небес что функция меняться не будет (как эта), то лучше не задумываться а писать что удобней.
С другой стороны, конечно, хорошо всегда писать правильно, по меньшей мере чтоб привычку нарабатывать.
arg1, arg2 — не информативно, и так понятно что процедура принимает первый аргумент, второй аргумент…
temp — возможно и лучше, но если функция занимает 3 строки, и есть гарантия от самих небес что функция меняться не будет (как эта), то лучше не задумываться а писать что удобней.
С другой стороны, конечно, хорошо всегда писать правильно, по меньшей мере чтоб привычку нарабатывать.
+1
С a, b и c могут возникнуть ненужные ассоциации. Например две функции рядом triangle_square(a, b, c) и swap(a, b). Если первая понятна любому, изучавшему геометрию в школе (и английский :) ), то этого же любого вторая может заставить полезть в реализацию. чтобы посмотреть, а что же там со сторонами треугольника происходит, хотя никакого отношения ни к треугльнику, ни геометрии вообще она не имеет. Правда arg1 и arg2 неудачные названия, я бы взял var1 и var2, подчеркнув, что нужно указывать именно переменные, а не произвольные выражения.
0
Есть ещё вариант — назвать «left» и «right» или «first» и «second»
0
swap — основы основ, название как бы намекает, что там за аргументы).
a, b, c — часто используются в высшей математике, алгебре и прочих весомых науках.
a, b, c — часто используются в высшей математике, алгебре и прочих весомых науках.
0
Вот и я про то, может возникнуть диссонанс между swap и её аргументами a и b. Вроде swap чисто техническое название, а a и b — научные.
0
Так хотелось найти пример, но боюсь что boost, .Net, Qt напилили что-то похожее на value1, value2 для таких функций((.
a,b — все-же скорей инженерные, нежели научные. Наука кишит всякими тау, гамма… Впрочем и а, b к сожалению тоже.
Ну ладно, буду делать как все, но аргумент в сторону сильных ассоциаций к a,b — не принимаю). Не верю в существование программистов, которые при виде swap(a, b) подумают про стороны треугольников.
a,b — все-же скорей инженерные, нежели научные. Наука кишит всякими тау, гамма… Впрочем и а, b к сожалению тоже.
Ну ладно, буду делать как все, но аргумент в сторону сильных ассоциаций к a,b — не принимаю). Не верю в существование программистов, которые при виде swap(a, b) подумают про стороны треугольников.
0
Непонятно. Что такое «треугольный квадрат»? Я такого не только не знаю, но и представить себе не могу. Или имелось в виду TriangleArea?
0
UFO just landed and posted this here
Всё же не все правила абсолютны.
Если они большие, то можно и по ссылке. Пару мегабайт данных на фига пихать в функцию «напрямую»?
Если в функции 7 входных параметров, все из которых используются и сама функция небольшая, то переопределение может занять больше места/времени чем использование их как рабочих и привести след. разработчика в задумчивость.
Фактически это обязательно только в публичном методе. Приватный метод вполне имеет право полагаться на проверку этих данных перед ним. Иначе в цепочке вызовов может оказаться такой копипаст проверок, что жуть.
Неизменяемые параметры не должны передаваться по ссылке.
Не используйте входные параметры в качестве рабочих переменных.
Метод должен быть защищен от плохих данных, которые могут нарушить его работу.
Если они большие, то можно и по ссылке. Пару мегабайт данных на фига пихать в функцию «напрямую»?
Если в функции 7 входных параметров, все из которых используются и сама функция небольшая, то переопределение может занять больше места/времени чем использование их как рабочих и привести след. разработчика в задумчивость.
Фактически это обязательно только в публичном методе. Приватный метод вполне имеет право полагаться на проверку этих данных перед ним. Иначе в цепочке вызовов может оказаться такой копипаст проверок, что жуть.
+4
Спрашивал месяц назад по этому вопросу того самого Джона Кармака в Твиттере. Он же увлекается всяким таким. Кармак сказал, что по вопросам читабельности кода самое лучшее — вот это.
Ссылок на PDF на английском если что хватает, а лично мне книга понравилась, легко читается легко и сразу есть практическая польза. Code Complete безусловно шире по охвату тем и сравнивать их не стоит, но вдруг кто-то и эту книжку возьмет на вооружение.
Ссылок на PDF на английском если что хватает, а лично мне книга понравилась, легко читается легко и сразу есть практическая польза. Code Complete безусловно шире по охвату тем и сравнивать их не стоит, но вдруг кто-то и эту книжку возьмет на вооружение.
+1
Конкретизация методов/функций/переменных нужна только там, где код, с первого прочтения, может быть не очевиден. Не нужно комментировать, что вы делаете, комментируйте почему вы так делаете.
0
Так же не мало важным является одинаковое оформление блоков кода, разбиение длинных условий на несколько строк и использование отступов.Приятно может быть и первый, но хорошим компромиссом для такой ситуации имхо было бы все-таки
Согласитесь, читать такой код:
Код красивыйfunction()
{
$a = 1;
$b = 2;
$c = 3;
$sql = '
SELECT
*
FROM
tbl
WHERE
a = 1';
}
Код компактныйfunction(){
$a = 1;
$b = 2; $c = 3;
$sql = 'SELECT * FROM tbl
WHERE a = 1';
}
Более приятно, чем
Код компромисный
function(){
$a = 1; $b = 2; $c = 3;
$sql = 'SELECT * FROM tbl WHERE a = 1';
}
$a = 1; $b = 2; $c = 3;
$sql = 'SELECT * FROM tbl WHERE a = 1';
}
Потому что первый тип кода приводит к тому, что частенько приходится пролистывать страницы. Код должен быть разумно компактен. Особенно учитывая моду последних лет, когда 4:3 мониторы скукожили до 16:10, а потом и до 16:9… или вообще сумашедшие 21:9 habrahabr.ru/post/145276/
+4
Метод не должен быть слишком большим (не более 100)
Не более чего? Строк/экранов/*байт/грамм? :)
+2
А разве не очевидно?
-1
Вам очевидно, мне очевидно, а тем, кому эта статья будет реально полезна, скорее всего может быть не очевидна.
-1
Знаете, если человек подумает про 100 экранов или 100 байт, ему лучше не продолжать программировать. Ему даже code complete не поможет. Всё таки у программистов должен быть мозг
+1
Да ладно. Вы реально весь такой правильный и никогда не делаете ошибок?
+3
При чем тут то делаю я ошибки или нет?
Я просто уверен что большинство тут люди с хорошими мозгами, и однозначно поняли о какой еденице измерения шла речь.
Метод размером 100 строк. Очевидно же.
Какие к черту байты, экраны? Зачем вы бред несете? Вам приятно ощущать себя дурачком?
Это серьёзный IT ресурс а не ясельная группа. Да, хабр сгавнивается с годами, все меньше серьёзных постов, но ведь это не повод устраивать смешнявочки из за недописок. Если вы нашли однозначную ошибку в статье — ну писните автору в ЛС. Зачем разводить детский сад?
Я просто уверен что большинство тут люди с хорошими мозгами, и однозначно поняли о какой еденице измерения шла речь.
Метод размером 100 строк. Очевидно же.
Какие к черту байты, экраны? Зачем вы бред несете? Вам приятно ощущать себя дурачком?
Это серьёзный IT ресурс а не ясельная группа. Да, хабр сгавнивается с годами, все меньше серьёзных постов, но ведь это не повод устраивать смешнявочки из за недописок. Если вы нашли однозначную ошибку в статье — ну писните автору в ЛС. Зачем разводить детский сад?
+2
Инженерия и наука требуют точных высказываний, которые не дают шанса термину «неоднозначность».
Да, было очевидно что там про строки, но оно просто сильнобесило выделялось и потому автор критики не мог пройти мимо.
Не принимайте близко к сердцу, практика показывает что в таких ситуациях дешевле будет сказать «Прошу прощения, поправил.»
Да, было очевидно что там про строки, но оно просто сильно
Не принимайте близко к сердцу, практика показывает что в таких ситуациях дешевле будет сказать «Прошу прощения, поправил.»
+1
Про очевидность я вам ответил выше.
Для вас очевидно (должно быть у вас есть мозг). Для меня очевидно (знаком с software metrics). A для кого-то начинающего может быть очевидно, что метод должен содержать не более 100 операций.
В итоге, не нравится мой комментарий — есть минус для него, есть минус в карму.
Выпустите пар на них и продолжайте читать сей серьёзный IT ресурс, вместо рассуждений на тему мозга у программистов.
Для вас очевидно (должно быть у вас есть мозг). Для меня очевидно (знаком с software metrics). A для кого-то начинающего может быть очевидно, что метод должен содержать не более 100 операций.
В итоге, не нравится мой комментарий — есть минус для него, есть минус в карму.
Выпустите пар на них и продолжайте читать сей серьёзный IT ресурс, вместо рассуждений на тему мозга у программистов.
0
Конечно все догодались, но для этого пришлось напрячь мозг на 0.5 секунд. Ирония в том, что это в статье про перфикционизм и про прекрасно офрмленный, легко-читабельный код. Если бы эта надпись была в любой другой статье — никто бы и не обратил внимание.
+2
Тут тоже всё очевидно:
Что тут не очевидного?
function(){
$a = 1;
$b = 2; $c = 3; $sql = 'SELECT * FROM tbl
WHERE a = 1'; return $this->my_sql->q($sql);
}
Что тут не очевидного?
0
Спасибо, исправил
+1
Очень напоминает пересказ одной из глав «Совершенного кода»
+5
Ах, автор об этом упомянул. Я воспользовался правилом «The Wadsworth Constant» и сразу начал читать со второй трети статьи.
+1
Всё это круто и интересно, но опять таки в вакууме.
Возьмите любой открытый проект, найдите в нём код, который некрасивый/несовершенный, сделайте его красивым и выкладывайте на обсуждение.
Возьмите любой открытый проект, найдите в нём код, который некрасивый/несовершенный, сделайте его красивым и выкладывайте на обсуждение.
+1
UFO just landed and posted this here
оформление SQL кода, с новой строки (как у меня), или придерживаюсь всех отступов — как у вас, уже пожеланию. Главное что бы был читаем SQL (beautiful query). Различия незначительны, лишь в количестве действий при наборе — у вас отступов больше :)
а по поводу скобок и пустых строк — это, как описано в топике — строго по гайдлайнам компании.
а по поводу скобок и пустых строк — это, как описано в топике — строго по гайдлайнам компании.
+1
Ничуть не слишком. Это удобно читать и камитить. Пример:
Весь «скелет» запроса виден по SELECT...FROM...LEFT JOIN...WHERE. Из какой таблицы выборка, что выбираем, с чем джоиним, по каким условиям. Запятые в начале для камитов. Если завтра потребуется добавить новое поле, то в дифе мы увидим ", iv.new", т.е. затронута будет одна строка, а не две как в случае если поля разделять запятыми в конце строки.
$sql = '
SELECT
i.e_id
, iv.iv_id AS id
, iv.value
, iv.ep_id AS element_property_id
FROM
' . $this->schema . '.item AS i
LEFT JOIN
' . $this->schema . '.item_value AS iv USING (i_id)
WHERE
i.i_id = '. $this->db->getSqlInt($item['id']) . '
';
Весь «скелет» запроса виден по SELECT...FROM...LEFT JOIN...WHERE. Из какой таблицы выборка, что выбираем, с чем джоиним, по каким условиям. Запятые в начале для камитов. Если завтра потребуется добавить новое поле, то в дифе мы увидим ", iv.new", т.е. затронута будет одна строка, а не две как в случае если поля разделять запятыми в конце строки.
0
LEFT JOIN я бы сдвинул ещё, всё таки он относится к FROM, а не является самостоятельным элементом SELECT.
А вообще, когда выражение простое вроде «SELECT * FROM table», то при виде его разбитым на 4 строки возникает неоднозначная реакция.
А вообще, когда выражение простое вроде «SELECT * FROM table», то при виде его разбитым на 4 строки возникает неоднозначная реакция.
+2
В JOIN, как и в FROM, находится имя таблицы, поэтому он вровень с FROM. Ведь по сути, работаем мы уже не с таблицей указанной во FROM, а таблицей полученной объединением. Поэтому в SELECT у нас имена полей, а в FROM...JOIN таблица.
Какой бы простой код не использовался, он должен соответствовать стилю кодирования. Это сильно облегчает чтение кода, а бОльшую часть времени на живом проекте мы все же читаем, а не пишем код. Разбиение на несколько строк очень полезно оказывается для дифов. При однострочной записи изменение любой чисти запроса приводит к включению в диф камита всего запроса, разделенный же на строки запрос в дифе дает только измененные строки. Крайне полезно при командной разработке, особенно при отслеживании камитов других разработчиков. Но и работая в одиночку подход показывает себя очень удобным. Читаемость должна находится на первом месте. Многословность форматирования легко может фикситься через минификацию/обфускацию на этапе сборке проекта. В контексте php это сборка в phar файл(ы).
Какой бы простой код не использовался, он должен соответствовать стилю кодирования. Это сильно облегчает чтение кода, а бОльшую часть времени на живом проекте мы все же читаем, а не пишем код. Разбиение на несколько строк очень полезно оказывается для дифов. При однострочной записи изменение любой чисти запроса приводит к включению в диф камита всего запроса, разделенный же на строки запрос в дифе дает только измененные строки. Крайне полезно при командной разработке, особенно при отслеживании камитов других разработчиков. Но и работая в одиночку подход показывает себя очень удобным. Читаемость должна находится на первом месте. Многословность форматирования легко может фикситься через минификацию/обфускацию на этапе сборке проекта. В контексте php это сборка в phar файл(ы).
0
Ну я сматриваю (а иногда и пишу) FROM… JOIN… ON… как FROM (… JOIN… ON ...), то есть имея ввиду как раз, что «аргументом» FROM является как раз «виртуальная» таблица, а состоит она из одной или объединения двух или более — не суть. Ваш вариант мне напоминает запись типа
а я предпочитаю
$var
=
2
+
2
а я предпочитаю
$var
=
2
+
2
0
Ну тут уж кому как удобно/какой стиль кодирования принят в проекте. Я лично за первый, т.к. идет разделение на уровне форматирования на оператор, идущий без отбивки, и его операнды, идущие с отбивкой слева. В твоем же случае два оператора, = и +, отбиты по разному. Хотя логика понятна «сложение 'внутри' присвоения».
0
>Читаемость должна находится на первом месте.
Согласен, вот только представления о ней у каждого свои :)
>Многословность форматирования легко может фикситься через минификацию/обфускацию на этапе сборке проекта. В контексте php это сборка в phar файл(ы).
Обычно это не нуждается в фиксе. А сборка php-проекта, по-моему, очень редкий зверь. Я так его наблюдал только когда пробовал HAML прикрутить к PHP из спортивного интереса.
Согласен, вот только представления о ней у каждого свои :)
>Многословность форматирования легко может фикситься через минификацию/обфускацию на этапе сборке проекта. В контексте php это сборка в phar файл(ы).
Обычно это не нуждается в фиксе. А сборка php-проекта, по-моему, очень редкий зверь. Я так его наблюдал только когда пробовал HAML прикрутить к PHP из спортивного интереса.
0
Редкий, просто потому что народ на это тупо забивает/не думает. Это как быдлокодинг. Но сбор проекта в один файл дает неплохой прирост. Поэтому я лично считаю этот аспект на столько важным, что хочу включить сборку в единый phar файл в своем проекте.
0
Информации о плюсах мало, а привычные сценарии разработки, разворачивания, обновления и поддержки (читай — правка кода на сервере :) ) ломает.
А вообще я больше не о phar (тут-то понятно, без сборки никуда), а вещах вроде «инлайна» инклудов, минимизации html, css и js, то есть препроцессинге и компиляции не в рантайме.
А вообще я больше не о phar (тут-то понятно, без сборки никуда), а вещах вроде «инлайна» инклудов, минимизации html, css и js, то есть препроцессинге и компиляции не в рантайме.
0
А зачем у вас перед FROM отступ? По логике ведь, эта строка не менее (а то и более) первостепенна, чем INNER JOIN.
+2
UFO just landed and posted this here
Кстати, я в WHERE отступы делаю по той же самой логике, вот так:
В случае с AND условия получаются ещё и выстроены на одном уровне.
SELECT *
FROM tbl
INNER JOIN tratata
ON zozo.zozo = zaza
WHERE a = 1
AND z = 1000
В случае с AND условия получаются ещё и выстроены на одном уровне.
+2
UFO just landed and posted this here
А я так пишу, удобней комментировать условия для отладки.
SELECT
tb1.*,
tb2.*
FROM
tb1
left join tb2 on tb1.id = tb2.id
WHERE
tb1.`date` = '2012-06-15' and
tb2.`date` = '2012-06-15' and
tb1.cat = 1
SELECT
tb1.*,
tb2.*
FROM
tb1
left join tb2 on tb1.id = tb2.id
WHERE
tb1.`date` = '2012-06-15' and
tb2.`date` = '2012-06-15' and
tb1.cat = 1
0
Я в последнее время после where всегда единицу ставлю, так удобней если какое-то условие закомментить нужно:
SELECT *
FROM tbl
INNER JOIN tratata
ON zozo.zozo = zaza
WHERE 1
AND a = 1
AND z = 1000
0
В аду есть специальный котел для тех, кто пишет открывающую фигурную скобку на новой строке :-)
-4
Хм, если честно, я сам всегда писал открывающую фигурную скобку на той же строке, где и сама функция, но сейчас я ограничен стандартами компании :)
+2
… и он пустует, потому что такие люди в ад не попадают? :)
Если серьёзно, то вот это уж точно является делом привычки. А также, традиций. В Java принято ставить открывающую фигурную скобку на той же строке, в C# — переносить.
Если серьёзно, то вот это уж точно является делом привычки. А также, традиций. В Java принято ставить открывающую фигурную скобку на той же строке, в C# — переносить.
+3
Насколько я помню ядро люнекса написано на таких скобках. Давным дано еще когда не было нормальных иде. так было удобней смотреть где открывается функция или условие и где заканчивается. Вот оттуда и понеслось.
0
Соблюдение стандартов кодирования важнее субъективного мнения о них. Главное чтобы в одном контексте было одинаково, например для классов и методов на новой строке ставить, а для if, for и т. п. в той же.
+1
Есть как минимум три соглашения о расстановке фигурных скобок в коде:
BSD style:
GNU style:
K&R style:
Какой из них использовать — зависит от соглашений, принятых в компании либо заданных самим языком.
К примеру, в Perl согласно Perl Best Practices рекомендуется использовать K&R style.
BSD style:
if(x == y)
{
something();
}
GNU style:
if (x == y)
{
something ();
}
K&R style:
if (x == y) {
something();
}
Какой из них использовать — зависит от соглашений, принятых в компании либо заданных самим языком.
К примеру, в Perl согласно Perl Best Practices рекомендуется использовать K&R style.
+3
В аду есть специальный котел для тех, кто разводит такие холивары.
Мое мнение — главное, чтобы везде было одинаково. И пох, с новой строки, или на той же строке.
Мое мнение — главное, чтобы везде было одинаково. И пох, с новой строки, или на той же строке.
0
А не хватит ли уже на Хабре писать однотипные статьи по оформлению кода?
Никакой новой инфы, которой не было в over 9000 таких же статей на тему «Как именовать переменные, методы и ставить отступы»
Никакой новой инфы, которой не было в over 9000 таких же статей на тему «Как именовать переменные, методы и ставить отступы»
+7
ага, читаешь интернет — и действительно, зачем столько однотипных статей, читаешь чужой код и понимаешь, что таких статей слишком мало, а каждому второму разработчику нужно стучать МакКоннелом по голове, чтобы не писал щуйни вроде
uuU_NEW+=uuUold-uuOLD
uuU_NEW+=uuUold-uuOLD
0
Вы подождите, еще про табы/пробелы никто не заикался…
OH SHI~…
OH SHI~…
0
Согласитесь, читать такой код:
…
Более приятно, чем
…
Вообще да, согласен с этим правилом, но именно в конкретном примере — не соглашусь. В первом случае пришлось скользнуть глазами по коду, чтобы прочитать, а во втором он сразу весь полностью попал в поле зрения и был понят куда быстрее.
P.S. Интересно, кстати, что раньше подобного за собой не замечал и сам всё всегда расписывал построчно.
…
Более приятно, чем
…
Вообще да, согласен с этим правилом, но именно в конкретном примере — не соглашусь. В первом случае пришлось скользнуть глазами по коду, чтобы прочитать, а во втором он сразу весь полностью попал в поле зрения и был понят куда быстрее.
P.S. Интересно, кстати, что раньше подобного за собой не замечал и сам всё всегда расписывал построчно.
0
> либо порядку их использования внутри метода
Странное правило. Вы предлагаете, чтобы сигнатура метода была завязана на его реализацию? А как же инкапсуляция? А если метод переопределяется, и в переопределённом методе порядок другой?
Вообще публичные методы должны быть определены в интерфейсах, где «использование внутри метода» вообще не предполагается, а порядок параметров в непубличных не так важен.
Странное правило. Вы предлагаете, чтобы сигнатура метода была завязана на его реализацию? А как же инкапсуляция? А если метод переопределяется, и в переопределённом методе порядок другой?
Вообще публичные методы должны быть определены в интерфейсах, где «использование внутри метода» вообще не предполагается, а порядок параметров в непубличных не так важен.
+2
К названиям методов, возвращающих boolean, полезно применять тоже правило что к boolean переменным. А именно:
vs.
или
file->checkViruses()
vs.
file->isVirusFree()
или
file->hasVirus()
+1
Имена булевых переменных должны быть в утвердительной форме и подразумевать булево значение: done, error, found, finished. Плохо: status, source.
можно еще добавлять is: isDone, isError, isFound
0
Можно было бы ограничиться последний ссылкой.
+2
Ребята (и автор) — это, конечно, все очень хорошо, копья ломаны не раз.
Хотел бы заметить совсем другое: нужно при оформлении кода ориентироваться на читающих, а не на всех.
То есть, если это мой единоличный проект, то его код, скорей всего не будут читать (зачем? рынок и без того перенасыщен приложениями и библиотеками), поэтому, имхо, глупо его красиво оформлять. Он должен удовлетворять лично мои потребности.
Если я пишу в команде, то неважно какой там кодстайл используется, важно, чтобы он был и был один. Читать его будет только команда. Новички скорее привыкнут к не очень им нравящемуся стилю, не нужно угождать им.
Если проект с открытыми исходными кодами… Думаю, аналогично. Конечно, потенциально его будут читать больше «левых» людей, но это как бы уже их проблемы.
Т.е. «я не 10$, чтобы всем нравиться» и «овчинка выделки не стоит».
Хотел бы заметить совсем другое: нужно при оформлении кода ориентироваться на читающих, а не на всех.
То есть, если это мой единоличный проект, то его код, скорей всего не будут читать (зачем? рынок и без того перенасыщен приложениями и библиотеками), поэтому, имхо, глупо его красиво оформлять. Он должен удовлетворять лично мои потребности.
Если я пишу в команде, то неважно какой там кодстайл используется, важно, чтобы он был и был один. Читать его будет только команда. Новички скорее привыкнут к не очень им нравящемуся стилю, не нужно угождать им.
Если проект с открытыми исходными кодами… Думаю, аналогично. Конечно, потенциально его будут читать больше «левых» людей, но это как бы уже их проблемы.
Т.е. «я не 10$, чтобы всем нравиться» и «овчинка выделки не стоит».
0
Правила оформления кода вносят в продукт примерно такой же вклад, как и геометрическая правильность кирпичей в готовый дом :) Хорошо когда они примерно одинаковы. Но бессмысленно добиваться абсолютной точности.
0
Добавлю от себя немножко:
1. Старайтесь избегать условных компиляций, да исключением #indef в заголовках. Если же угораздило вляпаться в мешанину #if, #ifdef, #else и т. п., то старайтесь делать условные блоки как можно короче, оформляйте операторы условной компиляции отступами и (желательно) подробными комментариями.
2. Не используйте табуляцию для оформления кода, заменяйте её пробелами. Если же используете табуляцию, то добейтесь, чтобы у всех участников проекта (сотрудников компании) настройки табуляции одинаковые (у всех должно быть задано использование табуляции с одинаковыми параметрами).
3. Вместо реального кода используйте как можно чаще константы, вычисляемые во время компиляции.
4. Для бекапа и обмена кодом используйте систему управления версиями (SVN, Git, Merqurial).
5. Уделяйте время для ведения сопроводительного дневника проекта — простого текстового файла, где делайте наброски алгоритмов, кратко записывайте, какие изменения были сделаны, описание проблем, замечания по оставшейся работе (todo).
1. Старайтесь избегать условных компиляций, да исключением #indef в заголовках. Если же угораздило вляпаться в мешанину #if, #ifdef, #else и т. п., то старайтесь делать условные блоки как можно короче, оформляйте операторы условной компиляции отступами и (желательно) подробными комментариями.
2. Не используйте табуляцию для оформления кода, заменяйте её пробелами. Если же используете табуляцию, то добейтесь, чтобы у всех участников проекта (сотрудников компании) настройки табуляции одинаковые (у всех должно быть задано использование табуляции с одинаковыми параметрами).
3. Вместо реального кода используйте как можно чаще константы, вычисляемые во время компиляции.
4. Для бекапа и обмена кодом используйте систему управления версиями (SVN, Git, Merqurial).
5. Уделяйте время для ведения сопроводительного дневника проекта — простого текстового файла, где делайте наброски алгоритмов, кратко записывайте, какие изменения были сделаны, описание проблем, замечания по оставшейся работе (todo).
-2
Не используйте табуляцию для оформления кода, заменяйте её пробелами.Абсолютная ересь.
Есть code convention, им определяется все.
-2
Табуляция объективно хуже тем, что не имеет постоянной ширины. В результате код, красиво выровненный с табами = 4 пробела, превращается в дикую лесенку при табах = 2 пробела.
Если нет иных code conventions, использую 2 пробела. Опыт показывает, что это идеал.
Если нет иных code conventions, использую 2 пробела. Опыт показывает, что это идеал.
+1
Переходя к практике: может кто-нибудь посоветовать настраиваемую утилиту форматирования кода? Потому что всё описанное (в части оформления кода) — это хорошо, но когда стандартные IDE не помогают вообще, сложно разношерстную команду подбить под одни правила. Или там, унаследовав от предыдущей команды сотню классов в произвольном форматировании, не хочется терять часы на форматирование ручками.
P.S. У меня конкретно MatLab, но я готов потратить время на конфигурацию готового продукта. Писать с нуля парсер не готов.
P.S. У меня конкретно MatLab, но я готов потратить время на конфигурацию готового продукта. Писать с нуля парсер не готов.
0
Наши соглашения о кодировании включают рекомендации из книги Герба Саттера и Андрея Александреску:
Стандарты программирования на C++. 101 правило и рекомендация.
Стандарты программирования на C++. 101 правило и рекомендация.
0
Кроме обеспечения удобочитаемости, соглашения должны служить цели снижения количества ошибок.
К примеру такое объявление переменных у нас запрещено, т.к. приводит к ошибкам:
или условные операторы без скобок также запрещены, т.к. можно дописать что-то, а скобки забыть:
Но снижение ошибок не должно быть важнее удобочитаемости, и по этому мы не следуем рекомендации писать константы перед переменными в сравнениях:
К примеру такое объявление переменных у нас запрещено, т.к. приводит к ошибкам:
int someCounter, someOtherValue = 0;
или условные операторы без скобок также запрещены, т.к. можно дописать что-то, а скобки забыть:
if (someValue == 0)
WriteTrace("Before do something"); // эта строчка была добавлена позже
DoSomething(); // ошибка, этот код будет вызываться даже если someValue != 0
Но снижение ошибок не должно быть важнее удобочитаемости, и по этому мы не следуем рекомендации писать константы перед переменными в сравнениях:
if (ERROR_SUCCESS != GetLastError()) // IMHO, снижает читабельность кода
0
Некоторые соглашения утверждают, что нужно обязательно ставить звездочку возле имени переменной, а не возле типа, т.к. это может привести к проблемам в следующей конструкции:
Но так, как у нас однострочное объявление запрещено, то мы спокойно пишем так, как нам удобно:
int *somePointer, *anotherPointer;
Но так, как у нас однострочное объявление запрещено, то мы спокойно пишем так, как нам удобно:
int* somePointer;
int* anotherPointer;
0
Спорные моменты по форматированию, такие как на какой строчке ставить скобку, либо где ставить пробелы, у нас принимались простым голосованием, т.к. нет четких доводов ни за ни против какого-либо варианта. В конечном итоге это не так ужи и важно, главное чтобы был один стиль в рамках проекта.
0
Еще, думаю, не стоит пытаться описывать в соглашениях все и сразу, стоит начать с малого. Также после некоторого времени становится ясно, что некоторые правила стоит изменить.
Соглашения — это живой документ, который развивается вместе с командой разработчиков, и отражает накопленный опыт.
Соглашения — это живой документ, который развивается вместе с командой разработчиков, и отражает накопленный опыт.
0
Sign up to leave a comment.
Оформление кода