pos = str.Find("smth");
if (-1 != pos) {...}
Какой код лучше? Копактный, сложный или длинный, простой?
Вычитал на форуме по Паскалю:
kerdan:
kerdan:
Цитата:
поверьте, лучше две чем пять.
если привыкнуть писАть компактный код, то потом если будете
изучать не компактный то будут возникать такие ситуации:
смотришь, смотришь, 1,2,3,5 строка и понимаешь - на хрен этот
ламер такую хрень расписывает на столько строк???
мозги со временем выработают дополнительные извилины, которые ни
кому еще не помешали и вам станет удобнее смотреть и писАть маленький код с высокой смысловой нагрузкой.
если привыкнуть писАть компактный код, то потом если будете
изучать не компактный то будут возникать такие ситуации:
смотришь, смотришь, 1,2,3,5 строка и понимаешь - на хрен этот
ламер такую хрень расписывает на столько строк???
мозги со временем выработают дополнительные извилины, которые ни
кому еще не помешали и вам станет удобнее смотреть и писАть маленький код с высокой смысловой нагрузкой.
Флудить на эту тему там не хочу, поэтому спрашиваю здесь.
Какой код лучше? Копактный, но сложный или длинный, но простой?
Сейчас, при программировании на Яве я пользуюсь парадигмой KISS. Достаточно простые участки кода приходится расписывать на несколько строк. Зато, сразу понятно, что делает тот или иной кусок кода.
Ваше мнение?
Цитата: Green
К вопросу о 'красоте кода':
...
согласись, так значительно читабельнее.
...
согласись, так значительно читабельнее.
Согласен на все 100%, что это гораздо читабельнее, но я делал по примеру <SCORP>
Цитата:
для меня сишные выражения типа if (-1 != (pos = str.Find("smth"))) {...} это нечто вроде отдушины
И насчет моего глюка, про присваивание - извините, был не прав. Посыпаю голову пеплом. Я оказывается наивно верил своему преподу в универе, когда он говорил, что if (i = 0)... выполнится всегда, т.к. логический результат присваивания true. Убедился, что это не так :).
Цитата: Green
Тогда есть несколько вариантов решения:
1. Аркадий начинает реже пить пиво, а больше учиться.
2. Сложные места, в которые Аркадий не въезжает, он начинает изучать при помощи юнит-тестов и консультации Бориса.
1. Аркадий начинает реже пить пиво, а больше учиться.
2. Сложные места, в которые Аркадий не въезжает, он начинает изучать при помощи юнит-тестов и консультации Бориса.
Для этого Аркадий должен учится, а он в это время пьет пиво. Согласно начальному условию :)
Цитата: Green
3. Стык программного кода Бориса и Аркадия они пишут вместе (парное программирование), т.о. Аркадий помимо выполнения задачи ещё и перенимает опыт Бориса.
Пожалуй это действительно вариант.
Цитата: Green
4. Если вышеперечисленное не осуществляется или не приносит результатов, увольняем Аркадия или перемещаем на другую работу, например, на кухню, мыть посуду. А на его место Борис наберет другого сотрудника и таким образом обеспечит высокую производительность команды.
Пока найдут замену Аркадию пройдет время и не факт, что замена будет отличаться в лучшую сторону. А время(или часть) отведенное на разработку к тому моменту будет потеряно.
ЗЫ. Кстати, изначально речь шла о братьях Стругацких, но это не имеет особого значения. Важен принцим работы разношерстной команды. :)
Тогда вопрос переадресовывается к <SCORP>.
[QUOTE=<SCORP>;164908]
а вообще, для меня сишные выражения типа if (-1 != (pos = str.Find("smth"))) {...} это нечто вроде отдушины :)
[/QUOTE]
почему бы не писать:
[QUOTE=<SCORP>;164908]а то, что это может не понять кто-то, кто не знает языка -- это я моя проблема, а его.[/QUOTE]
Надеюсьчтотызнаешьрусскийязыкиэтопрочестьсможешьоднакоспробеламиизнакамипрепинанияэтосделатьлегче.
[QUOTE=<SCORP>;164908]
а вообще, для меня сишные выражения типа if (-1 != (pos = str.Find("smth"))) {...} это нечто вроде отдушины :)
[/QUOTE]
почему бы не писать:
Код:
[QUOTE=<SCORP>;164908]а то, что это может не понять кто-то, кто не знает языка -- это я моя проблема, а его.[/QUOTE]
Надеюсьчтотызнаешьрусскийязыкиэтопрочестьсможешьоднакоспробеламиизнакамипрепинанияэтосделатьлегче.
Цитата: koltaviy
Чо за глупые ситуации?..
Ситуация более чем реальная.
Цитата: koltaviy
Если 'Аркадий':D любит пить пиво - пусть и пьет пиво, а не работает в комманде..
Работать-то он работает, но на своем низком уровне (copy/paste если хочешь :) ). А вот учиться он не хочет. Вообще.
Цитата: koltaviy
Я понимаю, если бы 'Борис' забивал на 'Аркадия' и позволял себе пить пиво.. Вот это было бы не совсем верно со стороны лучшего специалиста в комманде..
Борис забыл даже думать о пиве. На принудительное обучение Аркадия у него нет времени из-за множества других заданий по проекту.
Цитата: shine
Пока найдут замену Аркадию пройдет время и не факт, что замена будет отличаться в лучшую сторону. А время(или часть) отведенное на разработку к тому моменту будет потеряно.
Проблема ресурсов на проекте - роль не программиста, а менеджера. Менеджер должен найти выход из такой ситуации и не понижением общего уровня компетенции команды, а правильной организацией ресурса. Если менеджер не выполняет свои задачи так как надо, если он не может правильно распорядиться ресурсом, то проект с таким руководством обречен и зесь даже не в Аркадии будет дело.
Ремарка: хочу сразу заментить, что один человек может выполнять на проекте несколько ролей, т.е. Борис может быть как программистом, так и менеджером проекта. Однако, ресурсом он распоряжается именно, как менеджер и это не зависит от его программистской роли.
Пойми, что затраты на поддержку "слабого" (нерационального, неструктурированного) кода значительно превышают затраты связанные с поиском нового сотрудника или обучением существующего. Команде проще будет работать "неполным составом", чем тащить за собой лишний груз.
Цитата: shine
Работать-то он работает, но на своем низком уровне (copy/paste если хочешь :) ). А вот учиться он не хочет. Вообще.
Для чего тогда нужен такой работник?
Со временем возникнет вопрос об увольнении. Либо он совершенно перестанет удовлетворять условиям работы, либо его перестанет устраивать его з/п, а большее платить не за что, т.к. он не развивается, как специалист. Либо, что самое плохое, уволиться Борис, т.к. ему надоест это болото.
Если учесть, что IT - область быстроразвивающаяся и здесь "надо бежать, чтоб оставаться на месте", первый и третий варианты самые реальные.
Кроме того, подумай, какую идеальную компанию (свою или в которой хотел бы работать) ты видишь? Полную компетентных профессионалов, создающих шедевры инженерной мысли, говорящих на одном техническом языке, работающих, как один отлаженный механизм? Или же компанию с явными слабаками, которые тянут вниз общую эффективность труда, в которой хорошие программисты вынуждены подстраиваться под это болото?
Так вот любой умный работодатель стремиться к идеалу, а для этого надо избавляться от балласта, чем быстрее, тем лучше.
Цитата: shine
На принудительное обучение Аркадия у него нет времени из-за множества других заданий по проекту.
Это опять же проблема распределения ресурса.
1. Ни о каком принудительном обучении не может быть и речи. Человек должен хотеть. Если не хочет, надо сделать так, чтоб захотел (это называется мотивирование). Если же это "поная клиника" - избавляемся.
2. У Бориса должно быть время на обучение и об этом должен так же позаботиться менеджер.
3. Борис должен быть так же заинтересован (мотивирован) в обучении Аркадия. Замечание: мотивирован - не значит заинтересован финансово. Деньги, вообще,- плохой мотиватор.
[QUOTE=Green]Пойми, что затраты на поддержку "слабого" (нерационального, неструктурированного) кода значительно превышают затраты связанные с поиском нового сотрудника или обучением существующего. Команде проще будет работать "неполным составом", чем тащить за собой лишний груз.[/QUOTE]
Если бы это была аксиома, то все команды соостояли бы из одного человека, а зачем тратить время на поиски)
Жизнь сложнее и к каждой ситуации нужно подходить по-своему)
Искать может целенаправленно(тогда затраты минимальны) и не нужно, но если знаешь стоющего человека то нужно приглашать, знакомства иногда бывают полезны)
Так, что Аркадий сам уйдет, а пока он собираеться нужно порыться в телефонной книге, может там есть человек, который нужен или человек, который знает человека, который нужен и т.д.
Если бы это была аксиома, то все команды соостояли бы из одного человека, а зачем тратить время на поиски)
Жизнь сложнее и к каждой ситуации нужно подходить по-своему)
Искать может целенаправленно(тогда затраты минимальны) и не нужно, но если знаешь стоющего человека то нужно приглашать, знакомства иногда бывают полезны)
Так, что Аркадий сам уйдет, а пока он собираеться нужно порыться в телефонной книге, может там есть человек, который нужен или человек, который знает человека, который нужен и т.д.
[QUOTE='Frosty;165195']Если бы это была аксиома, то все команды соостояли бы из одного человека, а зачем тратить время на поиски)
[/QUOTE]
Не вижу связи с моим высказыванием.
Если мы говорим о проекте, который выполняется двумя программистами, один из которых явный балласт, то я утверждаю, что уменьшение команды до одного программиста повысит эффективность и сократит время разработки. Время разработки, если не принимать доп.меры, конечно, будет больше расчетного, но меньше, чем если бы они работали вдвоем.
[QUOTE=' Frosty;165195']
Жизнь сложнее и к каждой ситуации нужно подходить по-своему)
[/QUOTE]
Я отвечаю исходя из жизненного опыта.
Конечно, каждая ситуация имеет свои нюансы, но мы говорим об общей картине.
[QUOTE=' Frosty;165195']
Так, что Аркадий сам уйдет, а пока он собираеться нужно порыться в телефонной книге, может там есть человек, который нужен или человек, который знает человека, который нужен и т.д.[/QUOTE]
Это задача HR-менеджера. Есть такое понятие, как "подпирающий поток". Это довольно непростая задача. Суть её в том, что компания ведет такую политику на рынке труда, которая обеспечивает ей постоянный поток кандидатов вне зависимости от количества вакантных мест. Иными словами поиск кандидатов ведется и тогда, когда в них нет сиеминутной необходимости.
[/QUOTE]
Не вижу связи с моим высказыванием.
Если мы говорим о проекте, который выполняется двумя программистами, один из которых явный балласт, то я утверждаю, что уменьшение команды до одного программиста повысит эффективность и сократит время разработки. Время разработки, если не принимать доп.меры, конечно, будет больше расчетного, но меньше, чем если бы они работали вдвоем.
[QUOTE='
Жизнь сложнее и к каждой ситуации нужно подходить по-своему)
[/QUOTE]
Я отвечаю исходя из жизненного опыта.
Конечно, каждая ситуация имеет свои нюансы, но мы говорим об общей картине.
[QUOTE='
Так, что Аркадий сам уйдет, а пока он собираеться нужно порыться в телефонной книге, может там есть человек, который нужен или человек, который знает человека, который нужен и т.д.[/QUOTE]
Это задача HR-менеджера. Есть такое понятие, как "подпирающий поток". Это довольно непростая задача. Суть её в том, что компания ведет такую политику на рынке труда, которая обеспечивает ей постоянный поток кандидатов вне зависимости от количества вакантных мест. Иными словами поиск кандидатов ведется и тогда, когда в них нет сиеминутной необходимости.
[quote=Green]
почему бы не писать:
pos = str.Find("smth");
if (-1 != pos) {...}
[/quote]
Дело вкуса, но вот следующий код иначе не написать
Точнее можно, но будет очень неуклюже и с повторами :(
А оператор "?" использую не намного реже, чем "if". Так что склоняюсь к "компактному, но сложному коду". Правда с одной оговоркой: чем компактней упакован код, тем проще должны быть комментарии - хотя бы для самого себя через пол-года.
P.S.
Мне самому порою приходилось участвовать в совместных проектах. Временами доставалась роль "ватсона", а как научился - и "мегамозга".
Кстати, наличие рядом способного ученика частенько действует катализирующе на мастера.
почему бы не писать:
pos = str.Find("smth");
if (-1 != pos) {...}
[/quote]
Дело вкуса, но вот следующий код иначе не написать
Код:
// сравнивать с нулём быстрее ;)
for (int pos; (pos = str.Find ("Значение")) >= 0;)
{
...
}
for (int pos; (pos = str.Find ("Значение")) >= 0;)
{
...
}
Точнее можно, но будет очень неуклюже и с повторами :(
А оператор "?" использую не намного реже, чем "if". Так что склоняюсь к "компактному, но сложному коду". Правда с одной оговоркой: чем компактней упакован код, тем проще должны быть комментарии - хотя бы для самого себя через пол-года.
P.S.
Мне самому порою приходилось участвовать в совместных проектах. Временами доставалась роль "ватсона", а как научился - и "мегамозга".
Кстати, наличие рядом способного ученика частенько действует катализирующе на мастера.
Цитата: el scorpio
Дело вкуса,
"Вкус" тоже нужно воспитывать. :)
Цитата: el scorpio
но вот следующий код иначе не написать
Код:
// сравнивать с нулём быстрее ;)
for (int pos; (pos = str.Find ("Значение")) >= 0;)
{
...
}
for (int pos; (pos = str.Find ("Значение")) >= 0;)
{
...
}
Точнее можно, но будет очень неуклюже и с повторами :(
Условия циклов - это отдельный разговор.
Но опять же можно сделать так:
Код:
for (int pos;;)
{
pos = str.Find ("Значение");
if (pos >= 0) break;
...
}
{
pos = str.Find ("Значение");
if (pos >= 0) break;
...
}
Никаких неуклюжестей и повторов.
Цитата: el scorpio
Правда с одной оговоркой: чем компактней упакован код, тем проще должны быть комментарии - хотя бы для самого себя через пол-года.
А я вот практически не пишу коментариев. Код сам по себе является в первую очередь документом описывающим решение задачи, для чего его ещё и коментировать.
Так что наличие коментариев - это скорее показатель плохого кода. Код должен читаться без коментариев, т.е. быть самодокументированным. Это пожалуй единствено верное определение для "красивого" кода.
Цитата: el scorpio
Кстати, наличие рядом способного ученика частенько действует катализирующе на мастера.
Конечно, любое обучение не в последнюю очередь полезно самому обучающему.
Цитата: el scorpio
Дело вкуса, но вот следующий код иначе не написать
Код:
// сравнивать с нулём быстрее ;)
for (int pos; (pos = str.Find ("Значение")) >= 0;)
{
...
}
for (int pos; (pos = str.Find ("Значение")) >= 0;)
{
...
}
Я чувствую себя чайником :)
Читаю код и комменты:
// сравнивать с нулём быстрее - не информативный коммент
Код:
for (int pos; (pos = str.Find ("Значение")) >= 0;)
Сразу подозрение: а если str = "blablablaЗначениеbla" ?
Тогда получаем бесконечный цикл, если str где-то внутри не меняется.
Начинаем поиск str внутри этого цикла... и. т.п.
Можно ведь было в комментарии указать зачем вообще этот цикл?
Чтобы сразу было понятно, где, если что, баг искать.
Не пытайся вникать в примеры в отрыве от контекста.
В данном случае пример выглядит всего-лишь так:
и соотв-но возникает вопрос: почему бы не разнести:
В данном случае пример выглядит всего-лишь так:
Код:
цикл( условие(присвоение) )
и соотв-но возникает вопрос: почему бы не разнести:
Код:
цикл
присвоение
условие
присвоение
условие
Цитата: Green
Проблема ресурсов на проекте - роль не программиста, а менеджера. Менеджер должен найти выход из такой ситуации и не понижением общего уровня компетенции команды, а правильной организацией ресурса. Если менеджер не выполняет свои задачи так как надо, если он не может правильно распорядиться ресурсом, то проект с таким руководством обречен и зесь даже не в Аркадии будет дело.
Ремарка: хочу сразу заментить, что один человек может выполнять на проекте несколько ролей, т.е. Борис может быть как программистом, так и менеджером проекта. Однако, ресурсом он распоряжается именно, как менеджер и это не зависит от его программистской роли.
Пойми, что затраты на поддержку "слабого" (нерационального, неструктурированного) кода значительно превышают затраты связанные с поиском нового сотрудника или обучением существующего. Команде проще будет работать "неполным составом", чем тащить за собой лишний груз.
Ремарка: хочу сразу заментить, что один человек может выполнять на проекте несколько ролей, т.е. Борис может быть как программистом, так и менеджером проекта. Однако, ресурсом он распоряжается именно, как менеджер и это не зависит от его программистской роли.
Пойми, что затраты на поддержку "слабого" (нерационального, неструктурированного) кода значительно превышают затраты связанные с поиском нового сотрудника или обучением существующего. Команде проще будет работать "неполным составом", чем тащить за собой лишний груз.
Очень даже может быть. Но ведь вопрос не в том, как должен быть организован процесс разработки, а как поступать в случае плохой его организации. Взгляни на название топика :) Проблема существует и нужно как-то приспосабливаться сейчас. Само-собой, что нужно вносить изменения в управление проектами, но это может занять время, а решение по текущему проекту нужно принимать сейчас.
Цитата: Green
Кроме того, подумай, какую идеальную компанию (свою или в которой хотел бы работать) ты видишь? Полную компетентных профессионалов, создающих шедевры инженерной мысли, говорящих на одном техническом языке, работающих, как один отлаженный механизм? Или же компанию с явными слабаками, которые тянут вниз общую эффективность труда, в которой хорошие программисты вынуждены подстраиваться под это болото?
Так вот любой умный работодатель стремиться к идеалу, а для этого надо избавляться от балласта, чем быстрее, тем лучше.
Так вот любой умный работодатель стремиться к идеалу, а для этого надо избавляться от балласта, чем быстрее, тем лучше.
А если работодатель не умный, а жадный?
Знаешь, у меня такое ощущение, что ты описываешь какую-то идеальную ситуацию. Много ли ты знаешь работодателей в СПб, которые так организовывают дело как ты описал? В Днепропетровске я таких не знаю.
Цитата: Green
3. Борис должен быть так же заинтересован (мотивирован) в обучении Аркадия. Замечание: мотивирован - не значит заинтересован финансово. Деньги, вообще,- плохой мотиватор.
А что же, по-твоему, может быть хорошим мотиватором если не деньги?
Цитата: Green
Тогда вопрос переадресовывается к <SCORP>.
почему бы не писать:
Надеюсьчтотызнаешьрусскийязыкиэтопрочестьсможешьоднакоспробеламиизнакамипрепинанияэтосделатьлегче.
почему бы не писать:
Код:
pos = str.Find("smth");
if (-1 != pos) {...}
if (-1 != pos) {...}
Надеюсьчтотызнаешьрусскийязыкиэтопрочестьсможешьоднакоспробеламиизнакамипрепинанияэтосделатьлегче.
прочитать могу. но вряд ли это адекватное сравнение. когда я пишу код, то я его пишу НЕ ДЛЯ КОГО-ТО. я его пишу для проекта. и разбираться в нём буду в первую очередь я сам. поэтому и пишу так, как удобно МНЕ, а не кому-то, кто мало что понимает в С++. когда просят написать что-то и кому-то (в универе лабу и т.п.), тогда пишу "для людей" -- ясно, понятно и расписывая операторы на самые элементарные.
по поводу самодокументируемого кода я с Green почти согласен. не то, чтобы наличие комментариев было признаком плохого кода... но комментировать каждую или даже через одну строки кода просто нет надобности в большинстве случаев. а вот, например комменты к классам и методам в JDK ещё никому не мешали!
Цитата: shine
Проблема существует и нужно как-то приспосабливаться сейчас.
Печально, но я оказался прав. Ситуация с ИТ в Днепропетровске, видать совсем депрессивная. Добавлено позже: Хотя, по kot_у этого не скажешь.
Цитата: shine
Знаешь, у меня такое ощущение, что ты описываешь какую-то идеальную ситуацию.
Есть много выходов из "депрессии", начиная от питья водки в дупель и заканчивая переездом в город, где ситуация с ИТ получше.
Короче, программирование - не богослужение, и "проблемы присопособления" не существует. Уходи от такого работодателя, если сможешь - вопрос сам собой отпадёт.
ещё вариант : быстро и правильно работающий )
[QUOTE=<SCORP>;165240]когда я пишу код, то я его пишу НЕ ДЛЯ КОГО-ТО. я его пишу для проекта. и разбираться в нём буду в первую очередь я сам. поэтому и пишу так, как удобно МНЕ, а не кому-то, кто мало что понимает в С++.[/QUOTE]
А ты никогда не задумывался, что твой код будут потом читать Junior'ы?
Я прошел и Student уровень и Junior, хоть еще и маленький :) Основная задача тогда была исправить баги. И с непривычки читать 3-5 страниц кода, который написан достаточно "компактно" было очень сложно. На возражение - вот, надо учиться понимать сложный код - сразу скажу, сейчас, я пишу так, чтобы любой Junior мог понять, что же написано. Я имею ввиду и комментарии со смысловой нагрузкой, и расписывание кода чуть подлиннее. Зато, появляется наглядность. Кроме того, ведь как раз ради удобства придумали в Яве CodeConventions.
А ты никогда не задумывался, что твой код будут потом читать Junior'ы?
Я прошел и Student уровень и Junior, хоть еще и маленький :) Основная задача тогда была исправить баги. И с непривычки читать 3-5 страниц кода, который написан достаточно "компактно" было очень сложно. На возражение - вот, надо учиться понимать сложный код - сразу скажу, сейчас, я пишу так, чтобы любой Junior мог понять, что же написано. Я имею ввиду и комментарии со смысловой нагрузкой, и расписывание кода чуть подлиннее. Зато, появляется наглядность. Кроме того, ведь как раз ради удобства придумали в Яве CodeConventions.
[QUOTE=<SCORP>;165240]прочитать могу. но вряд ли это адекватное сравнение. когда я пишу код, то я его пишу НЕ ДЛЯ КОГО-ТО. я его пишу для проекта. и разбираться в нём буду в первую очередь я сам. поэтому и пишу так, как удобно МНЕ, а не кому-то, кто мало что понимает в С++.
[/QUOTE]
Ещё раз обращу внимание, что читабельность и владение языком - совершенно разные вещи.
Если ты предполагаешь, что я "мало что понимаю в С++", я могу развеять твои предположения. Если ты так не считаешь, тогда обрати внимание, что я утверждаю, что стиль приведенный тобой плохочитабелен и занимает дополнительное время на разбирательство, хотя я и довольно хорошо знаю язык.
На счет удобства, скажи, чем стиль который использовал ты в своём примере удобнее, чем тот, который показал я?
Манера запихивать всё в одну строку - это самообман, это ухудшает читабельность и структурированность кода, а следовательно увеличивает время на его понимание и модернизацию независимо от того, кто этим будет заниматься, ты сам или кто-то другой.
Я встречаю в своем старом коде похожие места и во многих случаях провожу их рефакторинг, в ходе которого раскрываются и потенциальные ошибки.
[QUOTE=<SCORP>;165240]
по поводу самодокументируемого кода я с Green почти согласен. не то, чтобы наличие комментариев было признаком плохого кода... но комментировать каждую или даже через одну строки кода просто нет надобности в большинстве случаев. а вот, например комменты к классам и методам в JDK ещё никому не мешали![/QUOTE]
Довольно часто встречается такая практика, когда программисты скупятся на имена функций, классов, пееменных, но при это щедро одаривают их коментариями.
[/QUOTE]
Ещё раз обращу внимание, что читабельность и владение языком - совершенно разные вещи.
Если ты предполагаешь, что я "мало что понимаю в С++", я могу развеять твои предположения. Если ты так не считаешь, тогда обрати внимание, что я утверждаю, что стиль приведенный тобой плохочитабелен и занимает дополнительное время на разбирательство, хотя я и довольно хорошо знаю язык.
На счет удобства, скажи, чем стиль который использовал ты в своём примере удобнее, чем тот, который показал я?
Манера запихивать всё в одну строку - это самообман, это ухудшает читабельность и структурированность кода, а следовательно увеличивает время на его понимание и модернизацию независимо от того, кто этим будет заниматься, ты сам или кто-то другой.
Я встречаю в своем старом коде похожие места и во многих случаях провожу их рефакторинг, в ходе которого раскрываются и потенциальные ошибки.
[QUOTE=<SCORP>;165240]
по поводу самодокументируемого кода я с Green почти согласен. не то, чтобы наличие комментариев было признаком плохого кода... но комментировать каждую или даже через одну строки кода просто нет надобности в большинстве случаев. а вот, например комменты к классам и методам в JDK ещё никому не мешали![/QUOTE]
Довольно часто встречается такая практика, когда программисты скупятся на имена функций, классов, пееменных, но при это щедро одаривают их коментариями.
Цитата: WandM
А ты никогда не задумывался, что твой код будут потом читать Junior'ы?
Нет, не задумывался и не задумываюсь.
Код может быть сложным с точки зрения уровня владения языком или областьи применения, но он должен быть простым с точки зрения читабельности и структурированности.
Цитата: Freeman
Печально, но я оказался прав. Ситуация с ИТ в Днепропетровске, видать совсем депрессивная. Добавлено позже: Хотя, по kot_у этого не скажешь.
Есть много выходов из "депрессии", начиная от питья водки в дупель и заканчивая переездом в город, где ситуация с ИТ получше.
Короче, программирование - не богослужение, и "проблемы присопособления" не существует. Уходи от такого работодателя, если сможешь - вопрос сам собой отпадёт.
Есть много выходов из "депрессии", начиная от питья водки в дупель и заканчивая переездом в город, где ситуация с ИТ получше.
Короче, программирование - не богослужение, и "проблемы присопособления" не существует. Уходи от такого работодателя, если сможешь - вопрос сам собой отпадёт.
Разговор шел не обо мне.
А насчет Днепропетровска: ситуация очень сложная, но пока не депрессивная.
Цитата: shine
Разговор шел не обо мне.
Ты задал вопрос: как приспособиться? Ответ: никак, приспосабливаться должны остальные.
Цитата: Green
Код может быть сложным с точки зрения уровня владения языком или областьи применения, но он должен быть простым с точки зрения читабельности и структурированности.
Согласен. Я подразумевал, что Junior'ы - это уже "прокачаные" по уровню владения языка люди, с маленьким опытом.
По крайней мере, так у нас в конторе.
[quote=WandM]
// сравнивать с нулём быстрее - не информативный коммент
[/quote]
Это был комментарий не к моему коду, а к оптимизации фрагмента, ранее привенного Green'ом. Ну не туда я строчку эту записал, не туда....
Самой большой ошибкой при написании комментариев, является скрупулёзно перечисление того, что делает код.
Комментарии нужны для того, чтобы пояснить зачем этот код - какую он несёт функцию с точки зрения.
[quote=SCORP]когда я пишу код, то я его пишу НЕ ДЛЯ КОГО-ТО. я его пишу для проекта. и разбираться в нём буду в первую очередь я сам. поэтому и пишу так, как удобно МНЕ, а не кому-то, кто мало что понимает в С++. когда просят написать что-то и кому-то (в универе лабу и т.п.), тогда пишу "для людей" -- ясно, понятно и расписывая операторы на самые элементарные.[/quote]
Для проекта - вот именно. Не для себя любимого, а для тех людей, которые будут разбираться с твоей программой, если вдруг уйдёшь в отпуск, заболеешь, уволишься или (тьфу-тьфу-тьфу через левое плечо).
Или всё равно, какими словами будут вспоминать коллеги?
// сравнивать с нулём быстрее - не информативный коммент
[/quote]
Это был комментарий не к моему коду, а к оптимизации фрагмента, ранее привенного Green'ом. Ну не туда я строчку эту записал, не туда....
Самой большой ошибкой при написании комментариев, является скрупулёзно перечисление того, что делает код.
Комментарии нужны для того, чтобы пояснить зачем этот код - какую он несёт функцию с точки зрения.
[quote=SCORP]когда я пишу код, то я его пишу НЕ ДЛЯ КОГО-ТО. я его пишу для проекта. и разбираться в нём буду в первую очередь я сам. поэтому и пишу так, как удобно МНЕ, а не кому-то, кто мало что понимает в С++. когда просят написать что-то и кому-то (в универе лабу и т.п.), тогда пишу "для людей" -- ясно, понятно и расписывая операторы на самые элементарные.[/quote]
Для проекта - вот именно. Не для себя любимого, а для тех людей, которые будут разбираться с твоей программой, если вдруг уйдёшь в отпуск, заболеешь, уволишься или (тьфу-тьфу-тьфу через левое плечо).
Или всё равно, какими словами будут вспоминать коллеги?