Комментарии 96
Нет, все-таки это страшно. После знакомства с VB на русском я частенько радуюсь, что когда пробовал просто VB английский знал (скорее, чувствовал) не ахти..
PS 1С-ки разве не скопировали автоформатирование кода из VB? Или оно есть, но работает из рук вон?
PS 1С-ки разве не скопировали автоформатирование кода из VB? Или оно есть, но работает из рук вон?
1С-ки разве не скопировали автоформатирование кода из VB? Или оно есть, но работает из рук вон?
Ух ты… Поискал в меню — и правда есть такой пункт :-)
Да это без разницы.Кому как нравится.А форматирование блоков в 1С даже лучше VB))И еще.В 1С8 добавили сворачивание(группировку) синтаксиса для Если..КонецЕсли.
Да, сильная фича. Извините, не сдержался.
Вы, я так понимаю, работаете с 1С? Пишете конфигурации?..
Знаете, что мне очень не нравится в ней.. Помимо всего прочего, что можно обозвать субъективным, есть один объективный аргумент — я ни разу не слышал, и, тем более, не видел альтернативной среды разработки. А нативная, внимание, личное мнение, вызывает у меня рвотные позывы. Есть вообще варианты-то?.. Или хотя бы бандлы для других редакторов (чуть не написал для TextMate;)?
Вы, я так понимаю, работаете с 1С? Пишете конфигурации?..
Знаете, что мне очень не нравится в ней.. Помимо всего прочего, что можно обозвать субъективным, есть один объективный аргумент — я ни разу не слышал, и, тем более, не видел альтернативной среды разработки. А нативная, внимание, личное мнение, вызывает у меня рвотные позывы. Есть вообще варианты-то?.. Или хотя бы бандлы для других редакторов (чуть не написал для TextMate;)?
под 7.7 - OpenConf
под 8.0 среда разработки вполне приличная =)
под 8.1 еще есть улучшения
под 8.0 среда разработки вполне приличная =)
под 8.1 еще есть улучшения
Вы знаете, я наверное сейчас глупость скажу, но все же. По-моему 1С предоставляет COM интерфейсы и классы, а так же можно использовать собственные COM классы в 1С. Поэтому Visual Studio тоже должна прокатить.
Или я не прав?
Или я не прав?
да уж."язык 1С это бэйсик, переведенный промтом" =)
отлично работает автоформатирование. После нее на дельфях писать прям мука. Все так неудобно....
Дело вкуса, конечно.. Но по мне, если уж писать что-то требующее скорость (или скорость и гуй), то на Си/++/#.. Для всего остального, кроме дикой математики, есть руби, питон, etc.. А Delphi для меня осталась в школе и начале универа.. Мне хватило двух коммерческих проектов, чтобы ее разлюбить..
если что-то писать, что требует быстрое выполнение проекта - то дельфи очень даже приемлимый вариант, тем более если там это какая-то прикладная программа
Кстати сказать, в упомянутой же 1С идёт набор программистов на Delphi
Вакансии :: Фирма «1С»
Вакансии :: Фирма «1С»
Дело не в том, на чем писать, а в том, что неудобно. Дайте юзабилити!
А все свои коммерческие проекты я пишу на "бэйсике, переведенном промтом" :)
А все свои коммерческие проекты я пишу на "бэйсике, переведенном промтом" :)
Три раза перечитал. Нихрена не понял в чем фишка :/
Согласен, что много вложенностей может негативно влиять восприятие отдельных блоков кода. Где заканчивается условие и т.д.
А уменьшение вложенности может ухудшить восприятие логики программы. Как по мне, то в приведенных примерах ДО - было более понятным с точки зрения функционала.
А уменьшение вложенности может ухудшить восприятие логики программы. Как по мне, то в приведенных примерах ДО - было более понятным с точки зрения функционала.
хмм, хотя первая процедура и была громоздкой но она легче читалась чем то что получилось. Буквально на этой неделе читал code complete =) и очень согласен с советом- располагайте правильное продолжение под условием if, а обработку ошибок и всякие исключительные случаи -в else.
Вы же благополучно сделали наоборот, для форматирования это стало лучше, но читабельность - из рук вон.
вот как я читал первый вариант (достаточно абстрактно):
Проверка. Если выполняется условие1, то сделаем некие действия, дальше если выполняется условие2 - начнем цикл по справочнику и для каждого элемента справочника проверим условие3 и сделаем некие действия, а если еще выполняется и условие4 - выполним еще действия
И вот как второй (в скобках внутренние комментарии к "мыслям" ):
проверка
Если условие1 неверно - выйдем (обалдеть, выход в самом начале процедуры, а че дальше то?).
(это уже потом додумал что если не вышли - что до делаем). Если еще не вышли - сделаем код1
Далее если условие 2 неверно - опять выйдем (ммм диарея ? куда опять выходим ?)
(ух ты, мы еще не вылетели) Если еще не вышли - сделаем код2
Далее начнем цикл по справочнику. Если не условие3 - продолжим... (эээ я не силен в 1с и для меня эта комбинация - полный маразм -а если условие3 верное что делаем то - не продолжаем, где второе развитие? какие есть варианты то ? )
что-то поделаем (блок кода 2) а если еще верное и 4 условие - сделаем блок кода 3
Вот если честно - из всего только последний кусок в цикле нормально можно читать. Остальное - очень очень трудное - всегда куда-то выходим, оставляя куски неотработанного кода. вообще плохой стиль выходить из процедуры в середине текста - так очень сложно следить за алгоритмом, типа че-то пошуршали, а потом выскочили. выход должен быть только 1 и в конце, если вам что-то не надо делать - заверните в if-else. Если в else ничего нету - напишите комментарий - ничего не делаем потому что...(например ... Х не инициализирован а в У нету данных, т.к. условие 2 не выполнилось - мы не можем оперировать неполностью загруженными данными.)
Если хотите улучшить читабельность кода - имхо может помочь следующее (пишу на полу-английском потому как русский язык программирования не могу воспринимать и думать на нем =) )
ps что-то в предпросмотре в теге
Вы же благополучно сделали наоборот, для форматирования это стало лучше, но читабельность - из рук вон.
вот как я читал первый вариант (достаточно абстрактно):
Проверка. Если выполняется условие1, то сделаем некие действия, дальше если выполняется условие2 - начнем цикл по справочнику и для каждого элемента справочника проверим условие3 и сделаем некие действия, а если еще выполняется и условие4 - выполним еще действия
И вот как второй (в скобках внутренние комментарии к "мыслям" ):
проверка
Если условие1 неверно - выйдем (обалдеть, выход в самом начале процедуры, а че дальше то?).
(это уже потом додумал что если не вышли - что до делаем). Если еще не вышли - сделаем код1
Далее если условие 2 неверно - опять выйдем (ммм диарея ? куда опять выходим ?)
(ух ты, мы еще не вылетели) Если еще не вышли - сделаем код2
Далее начнем цикл по справочнику. Если не условие3 - продолжим... (эээ я не силен в 1с и для меня эта комбинация - полный маразм -а если условие3 верное что делаем то - не продолжаем, где второе развитие? какие есть варианты то ? )
что-то поделаем (блок кода 2) а если еще верное и 4 условие - сделаем блок кода 3
Вот если честно - из всего только последний кусок в цикле нормально можно читать. Остальное - очень очень трудное - всегда куда-то выходим, оставляя куски неотработанного кода. вообще плохой стиль выходить из процедуры в середине текста - так очень сложно следить за алгоритмом, типа че-то пошуршали, а потом выскочили. выход должен быть только 1 и в конце, если вам что-то не надо делать - заверните в if-else. Если в else ничего нету - напишите комментарий - ничего не делаем потому что...(например ... Х не инициализирован а в У нету данных, т.к. условие 2 не выполнилось - мы не можем оперировать неполностью загруженными данными.)
Если хотите улучшить читабельность кода - имхо может помочь следующее (пишу на полу-английском потому как русский язык программирования не могу воспринимать и думать на нем =) )
procedure CheckState()
{
if(clause1)
{
DoCode1()
if(clause2)
foreach(spravochnik(:))
{
if(clause3)
{
docode2()
if(clause4)
docode3()
else
//если не вып усл4 то нельзя делать так-то
}
else
{// если не вып усл3 то мы не можем ничего сделать с элем справочника
}
}
else
{//мы не можем перебирать справочник потому что при невыполнении условия2 у нас проблема Х
}
}
else
{// первичная проверка неуспешна, значит у нас ошибка У
тут по хорошему надо информировать код\пользователя, вызвавшего проверку об ошибке в самом начала
}
}
procedure DoCode1()
{...}
procedure DoCode2()
{...}
procedure DoCode3()
{...}
ps что-то в предпросмотре в теге
нету вообще никакого форматирования... засунул все в pre, чтобы хоть читалось
ммм ну для начала я программист НЕ 1с (даже не знаю как написать, опять же переврут - написать "не программист 1с" - скажут ваще не программист, а дает советы ).
второй момент - если кто-то неправильно трактует то, что здесь написано, а потом бездумно копипэйстит это в жж - ну что ж - это его проблемы (а для меня это в очередной раз подтверждает что жж - мягко говоря - тинейджерская помойка, и на какие-то вменяемые оценки и критику кроме "гыгы" там можно не рассчитывать).
Еще раз скажу - я считаю, что делать возврат из процедуры в самом начале процедуры - это нехороший стиль, и для себя я это обосновываю тем, что в таком случае читающему сложнее понять почему вот именно тут и вывалились ( не тупо понятно как леммингу, что типа раз ретурн значит вывалились, а полный разбор алгоритма). В таком случае вы "не оставляете" пояснительных комментариев, или "разбирающий" не доходит до них - он проследил одну ветку в которой вы с какого-то фига вернули из процедуры херню, не поясняя откуда она взялась, почему, какие последствия этого и результаты. Если вы хотите писать код, который способны поддерживать только вы, чтобы вас не выгнали за этот быдлокодинг, потому что кроме вас в нем никто не разберется - вперед, вы на правильном пути. Если хотите чтобы ваш код легко читался, поддерживался и рефакторился, а также в силу своей понятности указывал на явные недостатки алгоритма или его реализации - почитайте рекомендации серьезных профессионалов( не мои =) ) - Макконела (Сode Complete), почитайте Writing Security Code, загляните в список объязательной к прочтению литературы Microsoft... в общем если хотите расти - надо работать над собой а не читать жж.
второй момент - если кто-то неправильно трактует то, что здесь написано, а потом бездумно копипэйстит это в жж - ну что ж - это его проблемы (а для меня это в очередной раз подтверждает что жж - мягко говоря - тинейджерская помойка, и на какие-то вменяемые оценки и критику кроме "гыгы" там можно не рассчитывать).
Еще раз скажу - я считаю, что делать возврат из процедуры в самом начале процедуры - это нехороший стиль, и для себя я это обосновываю тем, что в таком случае читающему сложнее понять почему вот именно тут и вывалились ( не тупо понятно как леммингу, что типа раз ретурн значит вывалились, а полный разбор алгоритма). В таком случае вы "не оставляете" пояснительных комментариев, или "разбирающий" не доходит до них - он проследил одну ветку в которой вы с какого-то фига вернули из процедуры херню, не поясняя откуда она взялась, почему, какие последствия этого и результаты. Если вы хотите писать код, который способны поддерживать только вы, чтобы вас не выгнали за этот быдлокодинг, потому что кроме вас в нем никто не разберется - вперед, вы на правильном пути. Если хотите чтобы ваш код легко читался, поддерживался и рефакторился, а также в силу своей понятности указывал на явные недостатки алгоритма или его реализации - почитайте рекомендации серьезных профессионалов( не мои =) ) - Макконела (Сode Complete), почитайте Writing Security Code, загляните в список объязательной к прочтению литературы Microsoft... в общем если хотите расти - надо работать над собой а не читать жж.
А как же проверка аргументов? Или с неправильными аргументами все равно будем проходить всю процедуру?
На мой взгляд вы как-то неправильно МакКоннела читали... Он немного не об этом писал.
На мой взгляд вы как-то неправильно МакКоннела читали... Он немного не об этом писал.
Code Complete, второе издание, русский перевод, с.383, выделено жирным шрифтом:
Упрощайте сложную обработку ошибок с помощью сторожевых операторов (досрочных return или exit).
Хорошее правило — die early.
Упрощайте сложную обработку ошибок с помощью сторожевых операторов (досрочных return или exit).
Хорошее правило — die early.
С возрастом к вам придет понимание, что иногда лучше показаться неправым в меньшем, чем попасть в еще больший просак, пытаясь объяснить, что именно вы имели в виду.
Ну, или не придет.
Ну, или не придет.
Я тоже буквально прочитав начало поста подумал посоветовать автору "Совершенный Код", имхо в нем все отлично написано, понятно и доступно.
Про аргументы - ответ в посте ниже. Никто не говорил что их не надо проверять, что вы все к ним так привязались. Если вам так хочется этого услышать - да, я был неправ написав про плохой стиль и не дав дополнительного комментария о том, что плохо так делать повсюду без оснований :P.
Если у вас процедура описывает полный алгоритм, то на выходе у нее - или успешное прохождение алгоритма или информация об ошибке. Если внутри алгоритма вы можете собрать и вернуть расширенные данные об ошибке - грех это не сделать. Никто конечно не запрещает вам возвращать всегда один результат "ну какая-то ошибка" и выкидывать из процедуры в любом месте. Я в данном случае предпочту собрать\вывести дополнительную информацию о том, что могло бы привести к ошибке (то, что попадает в else) или хотя бы прокомментировать альтернативные варианты развития (то что в else). т.к. во втором примере все такие доп комментарии, если они бы были - оказались размазанными по всему телу метода. Первый пример позволил бы сосредоточить такие пояснения в конце метода, что очень помогло бы человеку, который это отлаживал.
2neithere мы тоже так умеем - Code Complete, все то же самое но раньше, стр 347.
"Размещайте нормальный вариант после if, а не после else"
Не знаю что у автора за код, но я не воспринял
и
за нормальные варианты развития кода.
Если у вас процедура описывает полный алгоритм, то на выходе у нее - или успешное прохождение алгоритма или информация об ошибке. Если внутри алгоритма вы можете собрать и вернуть расширенные данные об ошибке - грех это не сделать. Никто конечно не запрещает вам возвращать всегда один результат "ну какая-то ошибка" и выкидывать из процедуры в любом месте. Я в данном случае предпочту собрать\вывести дополнительную информацию о том, что могло бы привести к ошибке (то, что попадает в else) или хотя бы прокомментировать альтернативные варианты развития (то что в else). т.к. во втором примере все такие доп комментарии, если они бы были - оказались размазанными по всему телу метода. Первый пример позволил бы сосредоточить такие пояснения в конце метода, что очень помогло бы человеку, который это отлаживал.
2neithere мы тоже так умеем - Code Complete, все то же самое но раньше, стр 347.
"Размещайте нормальный вариант после if, а не после else"
Не знаю что у автора за код, но я не воспринял
Если (Не Условие1) Тогда
Возврат;
КонецЕсли;и
Если (Не Условие3) Тогда
Продолжить;
КонецЕсли;за нормальные варианты развития кода.
Давнооо я такого бреда не читал. Если исключений в языке нет (а я так понимаю что в 1C их нет), то проверка правильности параметров и возврат ошибки (если они неправильные) - стандартное начало процедуры. Если есть, но вы, тем не менее, хотите что-то проверить не вызывая лишних исключений - тоже. Не знаю уж какие умные книжки вы там читали, но если вы этого не понимаете - то вы "ваще не программист", уж извините.
Как раз ЖЖ указывает на Coding Style используемый людьми, которые весьма немало заботятся о том, чтобы код мог поддерживать не только автор программы - почитайте там пункт 7, к примеру. Вам полезно будет. Особенно если вы программируете не только на 1С...
А ваш пример показывает что человек может прочитать кучу умных книжек но при этом ничему не научиться. Печально, но факт.
Как раз ЖЖ указывает на Coding Style используемый людьми, которые весьма немало заботятся о том, чтобы код мог поддерживать не только автор программы - почитайте там пункт 7, к примеру. Вам полезно будет. Особенно если вы программируете не только на 1С...
А ваш пример показывает что человек может прочитать кучу умных книжек но при этом ничему не научиться. Печально, но факт.
Я вас ждал =). Вас видно сильно задел мой пассаж на тему ваших знаний о компании Microsoft и их источников, что вы даже не вникнув особо в тему обсуждения и, увидев что b0rg упомянул о проверке аргументов, так сюда рванули и начали писать. Прямо приятно когда есть персональный враг :). Польщен.
>> Если исключений в языке нет (а я так понимаю что в 1C их нет)
Неправильно понимаете... Имеется такая конструкция языка
Попытка
// Некоторые действия;
Исключение
// Обработка исключительной ситуации;
КонецПопытки;
Неправильно понимаете... Имеется такая конструкция языка
Попытка
// Некоторые действия;
Исключение
// Обработка исключительной ситуации;
КонецПопытки;
>> Если условие1 неверно - выйдем (обалдеть, выход в самом начале процедуры, а че дальше то?).
Интересно, а где вы проверяете скажем входящие параметры (возьмем нетипизированный язык)? В конце всей функции? Или вы делаете один большой if (все правильно) { ...сто строк кода... } else { выход с ошибкой } ? Да уже забудешь к какому блоку этот else относится. И почему бы это не выйти сразу?
>> Если не условие3 - продолжим... (эээ я не силен в 1с и для меня эта комбинация - полный маразм -а если условие3 верное что делаем то
"Продолжить" (буквально continue) есть в любом ЯП, ну и умея писать хоть на чем-то уже не сложно догадаться что он делает в цикле.
Интересно, а где вы проверяете скажем входящие параметры (возьмем нетипизированный язык)? В конце всей функции? Или вы делаете один большой if (все правильно) { ...сто строк кода... } else { выход с ошибкой } ? Да уже забудешь к какому блоку этот else относится. И почему бы это не выйти сразу?
>> Если не условие3 - продолжим... (эээ я не силен в 1с и для меня эта комбинация - полный маразм -а если условие3 верное что делаем то
"Продолжить" (буквально continue) есть в любом ЯП, ну и умея писать хоть на чем-то уже не сложно догадаться что он делает в цикле.
2denver - входящие параметры проверяю на входе =) и по сути что вы описали (if{100 строк кода} - это нормальный подход. Только все ваши 100 строк (спагетти) кода я превращаю в логичный набор методов и поочередно или условно их вызываю. В компании где я работаю в Code Rules упоминался замечательный пункт (когда найду -процитирую точно, там не 1 документ =( ) - если тело метода занимает более 1 страницы текста - стоит серьезно задуматься о разбиение этого метода на несколько вспомогательных.
Обычно написание алгоритма в виде "ста строк кода" называется спагетти-кодом и говорит о слабом навыке декомпозиции алгоритмов.
про continue
это-то понятно но логически ЧИТАЕТСЯ эта комбинация очень странно (особенно на русском). Больше хотелось указать на злоупотребление условными и безусловными прерываниями алгоритма - это его очень сильно запутывает, когда читатель НЕ знает алгоритма и пытается его восстановить по тексту реализации.
Обычно написание алгоритма в виде "ста строк кода" называется спагетти-кодом и говорит о слабом навыке декомпозиции алгоритмов.
про continue
это-то понятно но логически ЧИТАЕТСЯ эта комбинация очень странно (особенно на русском). Больше хотелось указать на злоупотребление условными и безусловными прерываниями алгоритма - это его очень сильно запутывает, когда читатель НЕ знает алгоритма и пытается его восстановить по тексту реализации.
Давайте - мухи- отдельно, котлеты - отдельно.
Никто же не говорил, что 100 строк - это хорошо, и насчет того, что короткие методы в целом лучше длинных, тоже спорить глупо. Но все-таки если есть достаточное количество строк в одной ветке, и только одна - в другой, все-таки именно if лучше подходит для короткой (т.е. поддерживаю denver-а в этом). По крайней мере, сколько приходилось просматривать код, именно такой код читался лучше - не надо скроллить и смотреть "а что за за условие было изначально", чтобы понять else блок. Ссылки на Code Rules (тем более если их нет)- доказательство слабое ;). Бывает, что там написаны и правильные вещи (а в основном это так и есть), только их нужно понимать, а не просто применять, как написано. Насчет применения - это лично мое мнение, я думаю, что думающий разработчик именно этим и отичается от кодера. Если есть логическое объяснение этого правила в Code Rules - в студию :)
Никто же не говорил, что 100 строк - это хорошо, и насчет того, что короткие методы в целом лучше длинных, тоже спорить глупо. Но все-таки если есть достаточное количество строк в одной ветке, и только одна - в другой, все-таки именно if лучше подходит для короткой (т.е. поддерживаю denver-а в этом). По крайней мере, сколько приходилось просматривать код, именно такой код читался лучше - не надо скроллить и смотреть "а что за за условие было изначально", чтобы понять else блок. Ссылки на Code Rules (тем более если их нет)- доказательство слабое ;). Бывает, что там написаны и правильные вещи (а в основном это так и есть), только их нужно понимать, а не просто применять, как написано. Насчет применения - это лично мое мнение, я думаю, что думающий разработчик именно этим и отичается от кодера. Если есть логическое объяснение этого правила в Code Rules - в студию :)
Короткие методы - лучше, но только тогда, когда они выполняют какую-нибудь законченную операцию! Не надо плодить методов типа PrepareStructureXXXforYYY - они только усложняют дело заставляя перепрыгивать из одного места программы в другое, но ни в какой мере не облегчают понимание...
Позвольте с вами не согласиться. В современных IDE "перепрыгивание" в имплементацию процедуры - простейшее дело. А вот читабельность кода становится намного лучше.
При этом следует учитывать, что число «прыжков» тоже имеет значение.
Вообще, злоупотреблять лакомствами IDE тоже не надо, иначе преимущества просто исчезнут, а без IDE код вообще невозможно будет разобрать. Иногда разработчик ухитряется отключить логику и фантазию, заменив их отладчиком и код-навигатором, в результате чего приходится ради общего дела садиться рядом с ним и помогать думать. И заменять накодированный смутный поток сознания более простыми и общими конструкциями. К сожалению, был такой опыт.
Вообще, злоупотреблять лакомствами IDE тоже не надо, иначе преимущества просто исчезнут, а без IDE код вообще невозможно будет разобрать. Иногда разработчик ухитряется отключить логику и фантазию, заменив их отладчиком и код-навигатором, в результате чего приходится ради общего дела садиться рядом с ним и помогать думать. И заменять накодированный смутный поток сознания более простыми и общими конструкциями. К сожалению, был такой опыт.
Странно, а официальном гуиде от 1с именно такие методы и делаются. Наверное они все дураки ;)
в IF должна быть основная линия развития алгоритма, а не количество строк, сколько там строк - не важно, если много - вынесите отдельным методом, если мало - пишите как есть. В else попадаем в случае отклонения от алгоритма. Если основная ветка алгоритма приводит к ошибке - это воспринимается как то, что в большинстве случаев от работы алгоритма ждут ошибку.
Code Rules - внутренний документ компании, естественно, ссылка на него в инете не появится =). Объяснений там немного, просто его писали люди которые разрабатывают достаточно давно. И для меня их мнение - авторитетное. Вы же не просите у МакКоннела логических объяснений ? Также и я, не видя явных противоречий в такой рекомендации, буду ей следовать. К тому же такой подход мне нравится.
Code Rules - внутренний документ компании, естественно, ссылка на него в инете не появится =). Объяснений там немного, просто его писали люди которые разрабатывают достаточно давно. И для меня их мнение - авторитетное. Вы же не просите у МакКоннела логических объяснений ? Также и я, не видя явных противоречий в такой рекомендации, буду ей следовать. К тому же такой подход мне нравится.
Разумеется я хочу получить (и обычно получаю) от МакКоннела или любого другого "авторитета" логических объяснений.
В частности от вас хотелось бы получить объяснений вашему бреду. Особенно когда вас (как щенка) уже ткнули носом в обожаемого вами МакКоннела. Ещё раз повторю, если вы вдруг проглядели:
Code Complete, второе издание, русский перевод, с.383, выделено жирным шрифтом:
Упрощайте сложную обработку ошибок с помощью сторожевых операторов (досрочных return или exit).
Как вы это будете соотносить с вашими дурацкими высказваниями на тему "в IF должна быть основная линия развития алгоритма" ? С правилом я, в принципе, согласен - но как и любое правило для него есть исключение: если if используется для проверки параметров то, уж конечно, он должен "срабатывать" на неправильные действия, которые приводят к выходу из функции.
Что касается Code Rules, то у нас в подобном документе каждый пунки имеет подпункты Pros:, Cons: и Decision: которые позволяют понять - почему то или иное правило имеет место быть. Неужели у вас этих разделов нет и вы не можете их пересказать тут ? Сссылка на авторитет (тем более авторитет бог знает кого) - самый слабый аргумент в споре...
В частности от вас хотелось бы получить объяснений вашему бреду. Особенно когда вас (как щенка) уже ткнули носом в обожаемого вами МакКоннела. Ещё раз повторю, если вы вдруг проглядели:
Code Complete, второе издание, русский перевод, с.383, выделено жирным шрифтом:
Упрощайте сложную обработку ошибок с помощью сторожевых операторов (досрочных return или exit).
Как вы это будете соотносить с вашими дурацкими высказваниями на тему "в IF должна быть основная линия развития алгоритма" ? С правилом я, в принципе, согласен - но как и любое правило для него есть исключение: если if используется для проверки параметров то, уж конечно, он должен "срабатывать" на неправильные действия, которые приводят к выходу из функции.
Что касается Code Rules, то у нас в подобном документе каждый пунки имеет подпункты Pros:, Cons: и Decision: которые позволяют понять - почему то или иное правило имеет место быть. Неужели у вас этих разделов нет и вы не можете их пересказать тут ? Сссылка на авторитет (тем более авторитет бог знает кого) - самый слабый аргумент в споре...
подтверждение - тот же макконел, выше. А можно уточнить - как это "повторю" ? neithere тоже ваш аккаунт на Хабре ? Я читаю комментарии и отвечаю на них последовательно, особо в таких повторениях не нуждаюсь. Но вот ваше внимание мне особенно приятно, спасибо за то, что так внимательно обо мне заботитесь, вдуг я что пропущу.
Ааа - так это ты, "Аксиом Великий" ? Человек, который много знает и нифига не понимает ? Тоды ой - с такими "знатоками" спорить смысла не имеет: если человек видя два противоречащих друг другу факта из одной книги не пытается понять - почему они оба там приведены, то с ним спорить бессмысленно.
Neithere это не я. Это просто другой человек, который не просто собирает факты, а пытается выстроить из них целостную картину мира.
В ответе neithere была написана чушь - и похоже что Вам даже неясно что Вы написали чушь. А чушь там просто навиду. Именно: мы тоже так умеем - Code Complete, все то же самое но раньше, стр 347.. Так вот: в книге МакКоннела (как и во многих других), сначала приводятся общие правила, а потом разбираются более специфические ситуации - и, разумеется, если в этих ситуациях следует действовать "не по правилам", то это ни в коем случае не указывает ни на ошибку в правилах, ни на проблемы в обсуждении этих ситуаций - а просто указывает на то, что эти правила - неабсолютны.
Так что... ваши цитаты к обсуждаемой статье отношения не имеют: они относятся к более специфическому варианту, обмуждаемому neithere, а общее правило к ним неприменимо. И ваше умение цитировать - вам не поможет...
P.S. Если вы не знаете кто такой "Аксиом Великий" - прочитайте "Восьминулевые" Георгия Гуревича. Сразу станет понятно чем ваша логика отличается от человеческой...
Neithere это не я. Это просто другой человек, который не просто собирает факты, а пытается выстроить из них целостную картину мира.
В ответе neithere была написана чушь - и похоже что Вам даже неясно что Вы написали чушь. А чушь там просто навиду. Именно: мы тоже так умеем - Code Complete, все то же самое но раньше, стр 347.. Так вот: в книге МакКоннела (как и во многих других), сначала приводятся общие правила, а потом разбираются более специфические ситуации - и, разумеется, если в этих ситуациях следует действовать "не по правилам", то это ни в коем случае не указывает ни на ошибку в правилах, ни на проблемы в обсуждении этих ситуаций - а просто указывает на то, что эти правила - неабсолютны.
Так что... ваши цитаты к обсуждаемой статье отношения не имеют: они относятся к более специфическому варианту, обмуждаемому neithere, а общее правило к ним неприменимо. И ваше умение цитировать - вам не поможет...
P.S. Если вы не знаете кто такой "Аксиом Великий" - прочитайте "Восьминулевые" Георгия Гуревича. Сразу станет понятно чем ваша логика отличается от человеческой...
Кстати для ваших порождений уже тоже есть название: равиоли код. Как и многие другие я считаю его анти-паттерном: мешашина излишне мелко дроблёных компонентов/функций ничуть не лучше мешанины goto. В сущности эта та же проблема только на другом уровне.
Может быть вы и порождаете читаемый код, но ваша твёрдая уверенность в том что код в 100 строк нужно рефакторить "невзирая на" заставляет в этом усомниться...
Может быть вы и порождаете читаемый код, но ваша твёрдая уверенность в том что код в 100 строк нужно рефакторить "невзирая на" заставляет в этом усомниться...
Извините, но следовать советам, не понимая их сути — бессмысленно. Необходимо требовать объяснения. Иначе вы совершите обряд, а не целенаправленное рациональное действие.
Тот же Макконнелл очень часто сталкивает лбами взаимоисключающие (казалось бы) способы решения задачи. Иногда это способствовует развитию критического мышления у читателя.
Тот же Макконнелл очень часто сталкивает лбами взаимоисключающие (казалось бы) способы решения задачи. Иногда это способствовует развитию критического мышления у читателя.
Вы привели МакКонела, я привел МакКонела, цитаты не то что бы взаимоисключающие, но они противоречат больше личным мнениям в каждом посте. Меряться чей макконел длиннее - не вижу смысла. Ничего не имею против той цитаты вообще, но мне кажется, что автор рефакторил условие1 и условие2 не как проверки параметров, а как какие-то логические условия алгоритма. Если это проверки - правы вы, если это логика алгоритма - я с автором не согласен.
Так как речь идёт об 1С, то с вероятностью 99% это были проверки наличия/отсуствия требуемых реквизитов, параметров и т.п. Вопросы типа "Распоряжение подписано?" или "НДС уже заплочен?" или "Требуется выписка счёта-фактуры?".
Условие1 — проверка начальных параметров на корректность.
Условие2 — действительно было урезано бездумно. Та же участь едва не постигла и Условие4, но очень уж подозрительно-поганым мне такой вариант показался.
Условие3 — проверка соответствия очередной строки справочника определённым параметрам.
Лично я не думаю, что буду вносить коррективы в самый последний (добавленный) вариант сокращения, так как смотрится достаточно наглядно и чисто. Точнее, конкретно в данном случае. А на деле, там есть, над чем поработать.
Условие2 — действительно было урезано бездумно. Та же участь едва не постигла и Условие4, но очень уж подозрительно-поганым мне такой вариант показался.
Условие3 — проверка соответствия очередной строки справочника определённым параметрам.
Лично я не думаю, что буду вносить коррективы в самый последний (добавленный) вариант сокращения, так как смотрится достаточно наглядно и чисто. Точнее, конкретно в данном случае. А на деле, там есть, над чем поработать.
Только не в том случае, когда этот читатель - "Аксиом Великий". С такими "читателями", увы, ничего сделать нельзя...
Если надо, попрошу и у МакКоннела ;). Доводы, почему нужно в if заносить более короткий код, приведены, а вот в подкрепление противоположного подхода отсутствует :). Если нет объяснения, но Code Rules можно и не показывать - смысла в них нет. Люди, которые их писали, возможно (опять-таки, мы точно не знаем) понимали, о чем пишут, но не факт, что понимают те, кто сейчас их читают. Так что - прочтите еще раз, попробуйте их понять, и прикинуть, может, есть лучше варианты. Многие люди, кто сейчас в топике высказывается, тоже имеют достаточные опыт разработки и некоторые тоже писали Code Rules.
Получается вы рассматриваете код по его "длине", типа если короче - значит в if, если длиннее - в else. Мне нравится больше подход, когда в if попадает нормальное развитие алгоритма, в else ошибочное.
Ваши доводы про скроллинг к условию - может быть это и проблема если смотрим код в слабых IDE, серьезные IDE поддерживают схлопывание блоков и прочие вкусности навигации. И мне кажется, что заниматься подгонкой проверок и кусков кода под удобство чтения в notepad - такое же неестественное поведение, как подгонять "ширину" кода под 15 дюймовые мониторы, когда почти у всех стоят уже минимум 17, если не 19. То же самое со скроллингом - доводы не убедительны, еще бы добавили что на очень слабых машинах скроллинг может тормозить...
И еще вопрос - почему вы считаете подходы "разбиения кода по строкам " (denver) и "разбиения про логическим блокам" ("моё") - противоположными ? противоположные это когда 1ый говорит - делаем так, а второй говорит - делаем НАОБОРОТ. А тут любой из подходов - делаем ПО-ДРУГОМУ. Это конечно местами демагогия, но вот почему-то у многих тут есть склонность делить мир на черное и белое, типа "если не с нами то ПРОТИВ нас".
Первым постом тут я высказал свое мнение в защиту другого подхода и в итоге опять оказался врагом. Не просто оппонентом дискуссии, а почему-то именно врагом - все советуют еще раз перечитать макконела, коде рулезы, каких-то других авторов. Вот из всей дискуссии, в которой, по идее должна родиться какая-то истина, ответов, которые "ищут истину" плачевно мало, больше поучений из серии - да вы тут не-д'Артаньян, идите-ка учитесь быть д'Артаньянами, как мы. Я просто не хочу быть "как мы", и мне хотелось высказать СВОЕ мнение и СВОЙ взгляд на проблему. Если он не совпадает с мнением большинства - это может и повод задуматься, но не повод его сразу же поменять.
И пока еще я не поменял мнение, потому как ваши способы оценки кода, по количеству строк или читабельности самого кода (а не алгоритма) например - мне не нравятся, потому как я привык оценивать код по логической целостности, завершенности, ветвям развития алгоритма. Код это просто способ реализации алгоритма, и для меня оценка алгоритма - первична, а кода - вторична. Код - это не цель работы программиста, а способ достижения исходной цели - реализации алгоритма. Это все равно что считать годовые кольца у деревьев идущих на сруб дома - не все ли равно, молодое ли дерево нужной толщины, или старое - главное оно должно идеально лечь в сруб дома.
Ваши доводы про скроллинг к условию - может быть это и проблема если смотрим код в слабых IDE, серьезные IDE поддерживают схлопывание блоков и прочие вкусности навигации. И мне кажется, что заниматься подгонкой проверок и кусков кода под удобство чтения в notepad - такое же неестественное поведение, как подгонять "ширину" кода под 15 дюймовые мониторы, когда почти у всех стоят уже минимум 17, если не 19. То же самое со скроллингом - доводы не убедительны, еще бы добавили что на очень слабых машинах скроллинг может тормозить...
И еще вопрос - почему вы считаете подходы "разбиения кода по строкам " (denver) и "разбиения про логическим блокам" ("моё") - противоположными ? противоположные это когда 1ый говорит - делаем так, а второй говорит - делаем НАОБОРОТ. А тут любой из подходов - делаем ПО-ДРУГОМУ. Это конечно местами демагогия, но вот почему-то у многих тут есть склонность делить мир на черное и белое, типа "если не с нами то ПРОТИВ нас".
Первым постом тут я высказал свое мнение в защиту другого подхода и в итоге опять оказался врагом. Не просто оппонентом дискуссии, а почему-то именно врагом - все советуют еще раз перечитать макконела, коде рулезы, каких-то других авторов. Вот из всей дискуссии, в которой, по идее должна родиться какая-то истина, ответов, которые "ищут истину" плачевно мало, больше поучений из серии - да вы тут не-д'Артаньян, идите-ка учитесь быть д'Артаньянами, как мы. Я просто не хочу быть "как мы", и мне хотелось высказать СВОЕ мнение и СВОЙ взгляд на проблему. Если он не совпадает с мнением большинства - это может и повод задуматься, но не повод его сразу же поменять.
И пока еще я не поменял мнение, потому как ваши способы оценки кода, по количеству строк или читабельности самого кода (а не алгоритма) например - мне не нравятся, потому как я привык оценивать код по логической целостности, завершенности, ветвям развития алгоритма. Код это просто способ реализации алгоритма, и для меня оценка алгоритма - первична, а кода - вторична. Код - это не цель работы программиста, а способ достижения исходной цели - реализации алгоритма. Это все равно что считать годовые кольца у деревьев идущих на сруб дома - не все ли равно, молодое ли дерево нужной толщины, или старое - главное оно должно идеально лечь в сруб дома.
Первым постом тут я высказал свое мнение в защиту другого подхода и в итоге опять оказался врагом. Не просто оппонентом дискуссии, а почему-то именно врагом - все советуют еще раз перечитать макконела, коде рулезы, каких-то других авторов.
Наверное, всё из-за лишних эмоций. При этом, не всегда обоснованных.
Не принимайте близко к сердцу негатив и не трепите себе нервы :-) А я Вам плюс поставлю, чтобы не так обидно было :-)
Честно, когда создавал блог — не ожидал, что в нём будет столько склок.
Наверное, как в этом и есть разница в подходах - лично я считаю что код пишется именно для ЛЮДЕЙ, чтобы им было быстро и удобно в нем разбираться при его поддержке, компьютеру все равно какой именно код обрабатывать, понятный или нет (даже исходный код в статье был не так уж плох, но, думаю, каждый сталкивался с кодом, который читать очень трудно). Так что продолжать дискуссию бессмысленно - мы просто хотим достичь разных целей.
Смотря на аватар дёргал мышью, и думал: «Что-то загрузило проц… или же повис…?» =)
«Продолжить» (буквально continue) есть в любом ЯП, ну и умея писать хоть на чем-то уже не сложно догадаться что он делает в цикле.Кажется, не всегда…
The continue block is executed immediately after the main block and is primarily used as a method for executing a given statement (or statements) for each iteration, irrespective of how the current iteration terminated.© Perl: The Complete Reference
если складывается проблема высокой вложенности (бедные люди, кто будет в твоем коде разбираться), то можно сделать булеву функцию по используемым условиям и далее оперировать с ее значениями. Код становится красивым, но главное не забыть описать что эта функция собственно делает
Как уже выше написали, прием довольно спорный: замечательно читающаяся конструкция из вложенных условий, соответствующая связке "И", превращается в линейное "НЕ (НЕ ИЛИ НЕ)", которое в голове удержать сложнее. Вложенные блоки хоть свернуть можно.
Совет: купите "Совершенный код" Макконнелла. Там обсуждаемая тема рассмотрена весьма подробно.
не знаю кому как, но я обычно длинные куски "if ...else if ... else if"
заменяю на
хотя, при отсутствии испольнять какой то общайкод в конце можно и return'ом вываливаться, не вижу ничего зазорного...
заменяю на
...
do
{
if (bla1)
{
...;
break;
}
if (bla2)
{
...;
break;
}
}
while (false);
..общий кусок кода после проверок...
...
хотя, при отсутствии испольнять какой то общайкод в конце можно и return'ом вываливаться, не вижу ничего зазорного...
хотя при отсутствии необходимости испольнять какой-то общий кусок кода в конце можно и return'ом вываливаться, не вижу ничего зазорного..
ммм сакральный смысл do{} while(false) мне честно не понятен.
Все для того, чтобы работали break. Хотя читать такой код - просто наказание.
Именно. Для таких случаев есть goto :-) Хотя если приходится программировать на языках без goto, то приходится извращаться.
P.S. Не могу понять "ярых сторонников goto", которые при всём притом активно используют break и continue. Я считаю что break и continue - это ухудшенный вариант goto: в случае с goto хотя бы сразу ясно куда переход происходит... Не стоит забывать что запрет на goto вводится обычно чтобы улучшить читаемость кода, а не как самоцель!
P.S. Не могу понять "ярых сторонников goto", которые при всём притом активно используют break и continue. Я считаю что break и continue - это ухудшенный вариант goto: в случае с goto хотя бы сразу ясно куда переход происходит... Не стоит забывать что запрет на goto вводится обычно чтобы улучшить читаемость кода, а не как самоцель!
Хм... А чем именно if ... else if ... else не устраивает, что приходится писать ТАКОЕ?
когда-то тоде таким пользовался, но вообще-то для этого и существуют исключения, особенно когда ошибки по разному надо обрабатывать
Я мог не правильно понять, но, кажется, не рекомендуется использовать исключения для управляющей логики.
Теория и практика Java: Дебаты об исключениях
Теория и практика Java: Дебаты об исключениях
вообще в исходном примере это как раз ошибки, а не управляющая логика.
С break есть проблема в неочевидном синтаксисе. Если надо вывалиться изнутри for, break сразу выйдет не туда. Для этого в Яве и Перле есть break и last соответсвенно, но остается еще проблема с передачей типа и дополнительных данных.
Это, конечно. тоже можно решить, но читаемость - это гораздо более важная штука, чем кажется сначала.
С break есть проблема в неочевидном синтаксисе. Если надо вывалиться изнутри for, break сразу выйдет не туда. Для этого в Яве и Перле есть break и last соответсвенно, но остается еще проблема с передачей типа и дополнительных данных.
Это, конечно. тоже можно решить, но читаемость - это гораздо более важная штука, чем кажется сначала.
Все — ошибки? По логике вещей, на ошибку отчасти похожа первая проверка, но остальные скорее — условное выполнение, в зависимости от контекста. Повесить вместо первой проверки выброс исключения — это не противоречит ли гайдлайну Microsoft?
- Do not use exceptions for normal or expected errors, or for normal flow of control.
- You should return null for extremely common error cases. For example, a File.Open command returns a null reference if the file is not found, but throws an exception if the file is locked.
это если ошибки. кроме того исключения обходятся дороже чем do/break.
Дружно читаем книжку про рефакторинг от М. Фаулера
...и Code Complete Макконнелла. Я вообще не понимаю, как можно браться всерьез за программирование, не читая базовую литературу по методикам.
Очень хорошая статья. Со всем согласен. Чувствуется, что автор пишет свои собственные, очень правильные на мой взгляд мысли, а не стандартные шаблонные высказывания. Прочитал с большим интересом.
Каким-же откровением для этих, людей, станет case\when, switch...
В данном контексте можно переформатировать код блоками
switch … case? А можно пример?
Немного не в тему, правда, но все же :)
Какими прогами можно:
1. Сжать код
2. Удалить все коментарии
3. Закодировать исходный код (актуально для пхп без использования зенда)
???
Спасибо!
Какими прогами можно:
1. Сжать код
2. Удалить все коментарии
3. Закодировать исходный код (актуально для пхп без использования зенда)
???
Спасибо!
идеальный вариант это,как в редакторе скриптов AutoIT
Только среды разработки еще не переняли эту полезную возможность
ссылка на скрин 17 кб
http://img91.imageshack.us/img91/2103/qqqqqqqpm9.th.gif
Только среды разработки еще не переняли эту полезную возможность
ссылка на скрин 17 кб
http://img91.imageshack.us/img91/2103/qqqqqqqpm9.th.gif
бедняги.. а нельзя все эти ЕСЛИ и КОНЕЦЦЫКЛА заменить на if и фигурные скобки?
а ещё меня всегда интересовало, как вы пишете конструкции типа "ЕСЛИ (А > Б)" - ведь приходится раскладку переключать постоянно, или используете какие-нибудь альтернативные раскладки клавиатуры или пунто?
спасибо. и мои соболезнования.
а ещё меня всегда интересовало, как вы пишете конструкции типа "ЕСЛИ (А > Б)" - ведь приходится раскладку переключать постоянно, или используете какие-нибудь альтернативные раскладки клавиатуры или пунто?
спасибо. и мои соболезнования.
Верно. Бесконечные «игла в яйце, яйцо в утке, утка в зайце, заяц в шоке» откровенно мешают при разборе кода, 1С здесь не что-то уникальное — пачка вложенных условий в том же PHP читается ещё хуже. Особенно, когда плохо (никак, например) отформатировано.
Причина тривиальная: когда разработчик занимается рутиной, голова иногда отключается и работает только на алгоритм. И никуда от этого не деться. Так что рефакторинг, рефакторинг и ещё раз рефакторинг. Или сдвоенная (забыл, как правильно называется) разработка — когда один человек пишет, а второй в реальном времени смотрит, ЧТО он пишет.
Впрочем, последний способ мало кому по вкусу. :)
Причина тривиальная: когда разработчик занимается рутиной, голова иногда отключается и работает только на алгоритм. И никуда от этого не деться. Так что рефакторинг, рефакторинг и ещё раз рефакторинг. Или сдвоенная (забыл, как правильно называется) разработка — когда один человек пишет, а второй в реальном времени смотрит, ЧТО он пишет.
Впрочем, последний способ мало кому по вкусу. :)
> Или сдвоенная (забыл, как правильно называется) разработка — когда один человек пишет, а второй в реальном времени смотрит, ЧТО он пишет.
Правильно называется парное программирование. Спасибо за некропост :-)
Правильно называется парное программирование. Спасибо за некропост :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сокращение уровня вложенности