Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 282
>API упрощен до такой степени, что пользоваться им до отчаяния сложно.
Беда многих известных сервисов.
Беда многих известных сервисов.
А Вы сами пробовали реализовать api?
«Не надо ехать в Детроит, чтобы понять, как там воняет.» Доктор Хаус
1 — Я в таких случаях говорю понятнее «не надо быть гением в области математики, чтоб знать что 2х2=4»
2 — Доктор ваш говорил не «как там воняет» а «как там плохо»
(шутка основанная на том что слово «воняет» в английском языке на жаргоне означает «фигня»)
2 — Доктор ваш говорил не «как там воняет» а «как там плохо»
(шутка основанная на том что слово «воняет» в английском языке на жаргоне означает «фигня»)
Но чтобы понимать более сложные вещи(типа парадокса Монти Холла), надо знать матчасть :)
Кто спорит то?
Однако обязательно ли построить самому дом, перед тем как жаловаться на то что без лифта на 120-й этаж подниматься не удобно?
Что проще, оценить сложность использования, или создание собственного API?
Однако обязательно ли построить самому дом, перед тем как жаловаться на то что без лифта на 120-й этаж подниматься не удобно?
Что проще, оценить сложность использования, или создание собственного API?
Даже пойдём дальше, может отменим тестирование софта?
Люди занимающиеся тестированием ведь не имеют право указывать на ошибки, они же не программисты, от них не требовалось из кожи вон лезть чтоб реализовать фиг знает что, фиг знает какими путями, что они вообще могут знать о создании софта…
Фидбэк вообще запретить законодательно…
Люди занимающиеся тестированием ведь не имеют право указывать на ошибки, они же не программисты, от них не требовалось из кожи вон лезть чтоб реализовать фиг знает что, фиг знает какими путями, что они вообще могут знать о создании софта…
Фидбэк вообще запретить законодательно…
Отличный пост! В некоторых местах посмеялся от душа.
З.Ы. Египетские операторные скобочки ненавижу всей душой :)). Вспоминается комикс, где программист спрашивает у нового тимлида: «So, you are curly-bracket-on-the-same-line man or curly-bracket-on-the-next-line man»?
З.Ы. Египетские операторные скобочки ненавижу всей душой :)). Вспоминается комикс, где программист спрашивает у нового тимлида: «So, you are curly-bracket-on-the-same-line man or curly-bracket-on-the-next-line man»?
*от души
А я люблю египетские скобки и ненавижу те, которые на следующей линии=))
А, между прочим, «египетские скобки» — это кагбэ стандарт :)
java.sun.com/docs/codeconv/
java.sun.com/docs/codeconv/
… в Java
Да, извините, не дописал
учитывая распространенность Java — это и есть стандарт.
Т.е. все языки должны подчиняться стандарту Java?
ни в коем случае. понятно, что для того Delphi или python это вообще не имеет значения, но для С-подобных языков актуально.
я сам не очень люблю Java, но я за то, чтобы код был чистым и понятным и чтобы стиль был какой-то, даже пускай это будет стиль согласно Java Code Convention.
я сам не очень люблю Java, но я за то, чтобы код был чистым и понятным и чтобы стиль был какой-то, даже пускай это будет стиль согласно Java Code Convention.
было бы логичней говорить что для С-подобных языков более подходит С-подобный стандарт, а не давить на Java
Учитывая то, что это все же C-подобный синтаксис, я бы не стал делать таких заявлений.
Без проблем могу и так и эдак. С интересом наблюдаю со стороны за разборками между противниками и сторонниками.
Хорошие рассуждения на тему скобок есть в книшке «Совершенный код». Рекомендую.
Присоединяюсь. Вполне удобный стиль, и сам предпочитаю именно его.
<irony>Да и не зря ведь он назван «One True Brace Style» =) </irony>
<irony>Да и не зря ведь он назван «One True Brace Style» =) </irony>
оба стиля удобны, просто каждый выбирает свои удобства
Абсолютно с вами согласен.
Оба стиля удобы по-своему.
— Для стиля с переносом скобки на новую строку характена наглядность, т.к. явно выделены блоки, но при этом, увы, используется очень много вертикального пространства.
— Для египетских скобок характерна чуть меньшая наглядность (наример, при 4-уровневых вложенностях if-for), зато места гораздо больше.
Я лично строго придерживаюсь того стиля, который принят в команде программистов, где я работаю. А личное предпочтение отдаю стилю с переносом.
P.S. Еще бы IDE выделяли блоки, а строки со скобками скрывали — и место бы экономилось, и наглядность повышалась.
— Для стиля с переносом скобки на новую строку характена наглядность, т.к. явно выделены блоки, но при этом, увы, используется очень много вертикального пространства.
— Для египетских скобок характерна чуть меньшая наглядность (наример, при 4-уровневых вложенностях if-for), зато места гораздо больше.
Я лично строго придерживаюсь того стиля, который принят в команде программистов, где я работаю. А личное предпочтение отдаю стилю с переносом.
P.S. Еще бы IDE выделяли блоки, а строки со скобками скрывали — и место бы экономилось, и наглядность повышалась.
Люблю языки где можно обойтись без скобок
И я люблю :)
А мне нравистя оставлять на той же строке.
В этом случае я вижу оператор (if) и точно под ним завершающую скобку.
Если скобка на следующей строке, то получается лишняя строка, которая не добавляет читаемости.
В этом случае я вижу оператор (if) и точно под ним завершающую скобку.
Если скобка на следующей строке, то получается лишняя строка, которая не добавляет читаемости.
Именно так. Код получается более строгим и читаемым. В случае «неегипетских скобок» приходится использовать лишнюю табуляцию для индента — открывающаяся скобка отбивается одной табуляцией, код внутри операторных скобок соответственно двумя табуляциями. При вложенности операторных скобок количество табуляций по сравнению с «египетским» вариантом увеличивается вдвое. А если оставлять открывающуся скобку на уровне с предшествующим оператором — ухудшается наглядность.
Вы очень верно описали суть причины дискомфорта!
а разве сейчас кто-то пытается экономить «лишние» табуляции? код, который из-за табуляций еле влезает по ширине в экран нуждается в декомпозиции.
Дело не в табуляциях, а в том, что код содержит существенно больше строк и перестает влезать по высоте.
Я сам не люблю очень плотный код, когда одна функция сидит на другой, поэтому между функциями оставляю две строки вместо одной. Взамен я имею четкое видение кода «с высоты птичьего полета», просто по плотности текста, где функция, где разрыв. Но в данном случае, идет разрыхление внутри функций — код получается более рыхлый, монотонный, глазом хуже выхватываются блоки.
Я сам не люблю очень плотный код, когда одна функция сидит на другой, поэтому между функциями оставляю две строки вместо одной. Взамен я имею четкое видение кода «с высоты птичьего полета», просто по плотности текста, где функция, где разрыв. Но в данном случае, идет разрыхление внутри функций — код получается более рыхлый, монотонный, глазом хуже выхватываются блоки.
Нет, не понравилось как он работает.
фолдинг — он, конечно, позволяет спрятать то мясо, что кодер запихнул в функцию. И не видеть, что файл разросся. И класс. И…
Фу :)
Фу :)
ну, написание больших запросов, хранимых процедур и прочего реляционного фуфла — тема для отдельного нытья и холивора на годы.
Мое скромное мнение сводится к следующей мысли: разработчики БД немножко увлеклись и позабыли, что задача баз — хранение данных, а не программирование.
Довольно противный декларативный язык — SQL, отвратительные диалекты PL/SQL, бла-бла-бла… Я отдельным матерным словом обычно поминаю отстойнейший sqlplus, для которого за одиннадцать версий базы разработчики не сподобились даже просто повторить функционал либы readline
Фолдинг, не фолдинг, подсветка не подсветка… Этим больным поможет только смерть. :)
Так о чем мы? Ах да. Так а нафиг вам фолдинг? что позволяет вам делать? ну свернули вы if, while или switch. И что? Появилось чувство, будто ваша функция стала аккуратней и короче?
Мое скромное мнение сводится к следующей мысли: разработчики БД немножко увлеклись и позабыли, что задача баз — хранение данных, а не программирование.
Довольно противный декларативный язык — SQL, отвратительные диалекты PL/SQL, бла-бла-бла… Я отдельным матерным словом обычно поминаю отстойнейший sqlplus, для которого за одиннадцать версий базы разработчики не сподобились даже просто повторить функционал либы readline
Фолдинг, не фолдинг, подсветка не подсветка… Этим больным поможет только смерть. :)
Так о чем мы? Ах да. Так а нафиг вам фолдинг? что позволяет вам делать? ну свернули вы if, while или switch. И что? Появилось чувство, будто ваша функция стала аккуратней и короче?
Лучше смотреть на номер последней строки файла ) помогает
Эм, то есть Вы делаете вот так:
?
Это не правильно, надо так:
if(a)
{
foo();
}
?
Это не правильно, надо так:
if(a)
{
foo();
}
Поддерживаю
Кстати, а как вы делаете switch? Отхожу от стандарта, делая вот так:
<код>
switch( msg )
{
case WM_PAINT:
pDc->Rect( 0, 0, 128, 128 );
break;
case WM_QUIT:
…
}
</код>
<код>
switch( msg )
{
case WM_PAINT:
pDc->Rect( 0, 0, 128, 128 );
break;
case WM_QUIT:
…
}
</код>
Пардон, табуляторы съело :(
<код>
switch( msg )
{
case WM_PAINT:
pDc->Rect( 0, 0, 128, 128 );
break;
case WM_QUIT:
…
}
</код>
<код>
switch( msg )
{
case WM_PAINT:
pDc->Rect( 0, 0, 128, 128 );
break;
case WM_QUIT:
…
}
</код>
Они издеваются!
switch( msg )
{
____case WM_PAINT:
________pDc->Rect( 0, 0, 128, 128 );
________break;
____case WM_QUIT:
________…
}
switch( msg )
{
____case WM_PAINT:
________pDc->Rect( 0, 0, 128, 128 );
________break;
____case WM_QUIT:
________…
}
Мне почему-то больше близка такая конструкция:
Наверно, если бы делал, то делал так:
Но выглядит все равно как-то уродско.
if(WM_PAINT == msg)
{
foo();
}
else if(WM_QUIT == msg)
{
bar();
}
....
else
{
default();
}
Наверно, если бы делал, то делал так:
switch(msg)
{
case WM_PAINT:
foo();
break;
case WM_QUIT:
case 0:
bar();
break;
}
Но выглядит все равно как-то уродско.
вы просто не умеете их готовить.
switch(msg)
{
case WM_PAINT:
{
foo();
break;
}
case WM_QUIT:
case 0:
{
bar();
break;
}
}
А в case'ах зачем скобки?
Да, так получается красивее. Но break совсем не к месту, ведь он не несет смысла в блоке выполняемых операций.
Эх, Си, Си…
Вот enum в Java позволяет сделать это полиморфизмом, в итоге надобность в switch практически отпадает.
Вот enum в Java позволяет сделать это полиморфизмом, в итоге надобность в switch практически отпадает.
А мне ближе так (без лишнего отступа):
switch( msg )
{
case WM_PAINT:
pDc->Rect( 0, 0, 128, 128 );
break;
case WM_QUIT:
…
}
Да уж, наглядность значительно ухудшилась…
if (true) {
foo();
}
if (true)
{
foo();
}
Да ладно, дело вкуса :) По моему, особой разницы нет.
Главное не использовать оба стиля сразу, за это — руки отрывать.
Опять же — зависит от стайл-гайда. Популярный code conventions для перла рекомендует обычные скобки для основных функций и «ебипетские» — для всего остального.
sub foo($)
{
my $callback = sub {
# do something...
};
if (...) {
}
# и так далее
}
Ядро линукса вроде тоже таким стилем пишут. Функции в BSD-стиле, управляющие конструкции — в египетском.
lxr.linux.no/#linux+v2.6.34/Documentation/CodingStyle
lxr.linux.no/#linux+v2.6.34/Documentation/CodingStyle
+1 много где такой стандарт кодирования, например, в Zend Framework на похапе.
А хороший стиль, надо перенять.
Но не везде/не всегда. Как раз именно в перле выгодно фигурные скобки на отдельных строках использовать для обозначения многострочных блоков (вкупе с использованием завершающих точек с запятой в них для определённости), а египетские — для хэшрефов (поскольку последние тоже могут занимать большие пространства):
sub foo
{
return somefunc( {
number => 42,
string => 'asdf',
code =>
sub
{
#callback;
},
array => [ grep { defined; } @_ ],
});
}
Но в любом случае стиль кодирования на перле задать однозначно невозможно, т.к. существует тысячи областей его применения.
sub foo
{
return somefunc( {
number => 42,
string => 'asdf',
code =>
sub
{
#callback;
},
array => [ grep { defined; } @_ ],
});
}
Но в любом случае стиль кодирования на перле задать однозначно невозможно, т.к. существует тысячи областей его применения.
Вообще, современные IDE творят чудеса и могут привести весь код к заданному стилю одним нажатием хоткеев :)
Опять же, это не про перл. Его даже perl-tidy не всегда берет…
Как раз про перл. perltidy если не берёт Ваш перл, это сигнал начать менять свой стиль или уволить своего программиста.
Ваш комментарий был бы значительно полезнее если бы Вы сказали какой хоткей в какой IDE приведет код к одному стилю.
Да, могут, но только в пределах своей компетенции. А, хотя они и довольно-таки мощные, некоторые отдельные фишки в некоторых IDE отсутствуют, причем в каждой — свои.
Например, в IntelliJ IDEA вроде бы все здорово, но иногда мне хочется форматировать не весь JavaDOC, а только пустые строки и @param, @return и т.д., при этом НЕ форматировать остальной текст. Увы, IDE этого не умеет, и приходится отрубать автоформатирование JavaDOC.
Например, в IntelliJ IDEA вроде бы все здорово, но иногда мне хочется форматировать не весь JavaDOC, а только пустые строки и @param, @return и т.д., при этом НЕ форматировать остальной текст. Увы, IDE этого не умеет, и приходится отрубать автоформатирование JavaDOC.
На мой взгляд, первый вариант существенно лучше, чем второй.
Вот к чему там открывающая скобка? Ради чего ей выделена отдельная строка?
В первом случае четко видно — вот он if, а вот закрывающая его }.
Во втором я вижу { и }, но все равно мне нужно еще проверить к чему они относятся — то есть найти if.
Вот к чему там открывающая скобка? Ради чего ей выделена отдельная строка?
В первом случае четко видно — вот он if, а вот закрывающая его }.
Во втором я вижу { и }, но все равно мне нужно еще проверить к чему они относятся — то есть найти if.
Как по мне, то это дело привычки. Для разработки в команде помогают Code Conventions. Если вы пишите сам — то кавычка не является критичным местом.
Когда лично я пишу код (или просматриваю чей-то), мне всегда приходиться искать открывающую скобку если она находиться в строке оператора, на что тратиться время. Поэтому предпочитаю не использовать «египетский» вариант.
Когда лично я пишу код (или просматриваю чей-то), мне всегда приходиться искать открывающую скобку если она находиться в строке оператора, на что тратиться время. Поэтому предпочитаю не использовать «египетский» вариант.
Когда лично я пишу код (или просматриваю чей-то), мне всегда приходиться искать открывающую скобку если она находиться в строке оператора, на что тратиться время. Поэтому предпочитаю не использовать «египетский» вариант.
Именно! У меня карьера программиста началас с большого уже существующего проекта, поэтому просматривать чужой код приходится ооочень много.
Еще я заметил, что те, кто ставит египетские скобочки, обычно пишут так:
if (condition)
DoSmth();
или, что вообще ужасно, так:
if (condition) DoSmth();
В таких случае у меня глаз за if'ы вообще не «цепляется».
а я заметил, что те, кто не ставит египетские скобки пишут так.
я предпочитаю только египетские скобки, но так, как вы показали не пишу никогда
я предпочитаю только египетские скобки, но так, как вы показали не пишу никогда
может потому так пишут те, кто не ставит египетские скобки?
те кто пишут скобочку на следующей строке, итак не экономят место, им не жалко лишней строки для скобочки, какой смысл ее игнорировать? это те кто пишут в египетском стиле экономят место (обычно это первый аргумент — экономия строк) так что и проигнорировать закрывающую скобочку за глаза могут, это ведь целая строка
Я всегда пишу if (condition) DoSmth();
Потому что это фактически один оператор, а индент для меня — явный указатель на под-блок кода.
Таким образом, если я напишу
if (condition)
DoSmth();
То будет создана ошибочная видимость нового блока.
Заводить же ради одного оператора новый блок — растягивает код чересчур сильно. На моей скромной девятнашке это не позволяет видеть код целиком в некоторых случаях.
Потому что это фактически один оператор, а индент для меня — явный указатель на под-блок кода.
Таким образом, если я напишу
if (condition)
DoSmth();
То будет создана ошибочная видимость нового блока.
Заводить же ради одного оператора новый блок — растягивает код чересчур сильно. На моей скромной девятнашке это не позволяет видеть код целиком в некоторых случаях.
Что-то в вашей консерватории не так.
1) длина метода больше 20 строк — уже плохо.
2) Отсутствие скобок означает легко (и часто!) возникающую проблему при поддержке/дописывании кода.
скобки на следующей строке — без отступа — это православно )
1) длина метода больше 20 строк — уже плохо.
2) Отсутствие скобок означает легко (и часто!) возникающую проблему при поддержке/дописывании кода.
скобки на следующей строке — без отступа — это православно )
Я делю код на функции по смыслу. А не потому, что кто-то сказал, что функции должны быть по 8 строк (например). Где-то удобнее функция на 2 строки, а где-то и 40 строк бывает, если она делает одну конкретную неделимую задачу.
вторая причина более четко формирует почему отсутствие скобочек — плохо, я сам лично сталкивался с глюками по этому поводу, и ловить их трудно
не встречался с этим оО
может подскажете? )
может подскажете? )
банально длинное условие в ифе, которое выходит за край экрана, и за ним какое-то действие на следующей строке, и дальше какие-то действия, я думаю что после ифа скобка открывающая, и дописываю что-то нужное мне, проверяю, с первого взгляда работает, но нот фиа не слушается… как-то так
Когда пишу на PHP, я активно использую аббревиатуру
После написания
в эту аббревиатуру добавились фигурные скобки.
Думаю, с if что-то аналогичное.
echo "<pre>"; var_dump($varName); echo "</pre>";После написания
try {
//...
}
catch (Exception $e) echo "<pre>"; var_dump($varName); echo "</pre>";
в эту аббревиатуру добавились фигурные скобки.
Думаю, с if что-то аналогичное.
Ну тут само собой нужны скобки, т.к. тут три оператора, а не один.
У меня такие правила —
1. Никогда, НИКОГДА!!! Не писать более одного оператора в строке.
2. Стараться не разбивать оператор на несколько строк, если он такой длинный — следует его отрефакторить.
3. Если в ифе один оператор — обойтись без фигурных скобок.
У меня такие правила —
1. Никогда, НИКОГДА!!! Не писать более одного оператора в строке.
2. Стараться не разбивать оператор на несколько строк, если он такой длинный — следует его отрефакторить.
3. Если в ифе один оператор — обойтись без фигурных скобок.
А вот отлаживать такой код геморно, особенно когда у вас максимум четыре бриктопинта дебагер поддерживает, и step into не пашет.
И приходится в таких местах разварачивать это дело в несколько строк.
Я тоже раньше любил в одну строчку писать, потом желание отпало :)
И приходится в таких местах разварачивать это дело в несколько строк.
Я тоже раньше любил в одну строчку писать, потом желание отпало :)
для таких случаев хорошим решением является перенять стиль из питона:
я именно так и делаю, за редким исключением.
исключение:
if(cond)
DoSmth();
я именно так и делаю, за редким исключением.
исключение:
if(cond)
DoSmth();
else return false;
Вообще-то обычно их не отбивают. И вообще редко видел, чтобы отбивали — так чиатемость ухудшается.
> В этом случае я вижу оператор (if) и точно под ним завершающую скобку.
у вас все операторы if такие короткие?
у вас все операторы if такие короткие?
А зачем вообще использовать скобки для условий с одним оператором?
В Python'е вопрос скобок решили более кардинальным(и очень удобным) методом :)
«Египетские» операторные скобки имхо наиболее приемлимый вид операторных скобок в C-подобных языках. Даже если Стив Макконнелл говорит обратное.
Макконнел как раз рекомендует использовать либо «египетские» скобки, либо такой стиь:
void foo()
{
bar();
}
Макконнел очень суров я смотрю
Специально залез в Маконнела, перепроверить и он предлагет сеипл:
void foo()
{
bar();
}
void foo()
{
bar();
}
Прошу прощения.
void foo()
{
bar();
}
void foo()
{
bar();
}
Вобще то, я тоже открывал книгу, прежде чем писать комментарий. Второе издание (Питер 2005) 729 страница:
Избегайте отсутствия отступов в парах begin-end В стиле форматирования, проиллюстрированном в листинге 31-24, пара begin-end выровнена по границе управляющей структуры, а в выражениях, охватываемых операторами begin и end, сделаны отступы относительно begin.
Листинг 31-24. Пример пары begin-end, не выделенной отступами (Java)
//Ключевое слово begin выровнено по границе for. for(int i = 0; i < MAX_LINES; i++ ) { //В выражениях сделан отступ относительно begin. Readl_ine( i ); Processl_ine( i ); //Слово end также выровнено по границе структуры for. }
Хотя такой подход выглядит хорошо, он нарушает Основную теорему форматирования, так как не показывает логическую структуру кода. При таком расположении begin и end не являются частью управляющей структуры, но в то же время, они не являются и частью блока выражений, расположенного далее.
Любят же люди скобки обсуждать… Нам, питонщикам, не понять сути проблемы — она чужда нам.
А если точнее — не важно, КАК и ГДЕ вы ставите скобки, важно, чтобы оформление было ОДИНАКОВЫМ. Но почему-то не все это знают и понимают…
А если точнее — не важно, КАК и ГДЕ вы ставите скобки, важно, чтобы оформление было ОДИНАКОВЫМ. Но почему-то не все это знают и понимают…
Присоединяюсь к любителям египетских скобок.
В этом стиле четко видны блоки.
1 indent = 1 уровень вложенности.
В этом стиле четко видны блоки.
1 indent = 1 уровень вложенности.
В чем проблема с вложенностью в
?
if (true)
{
foo();
}
?
Субъективно мне труднее это воспринимать.
Данный вариант я прочитаю как отдельный «оператор» if (хотя он оператором не является) и отдельный блок без каких-либо условий (синтаксис Си такие блоки позволяет). Меня это путает)
Данный вариант я прочитаю как отдельный «оператор» if (хотя он оператором не является) и отдельный блок без каких-либо условий (синтаксис Си такие блоки позволяет). Меня это путает)
Пока писал на c++ и c# — пользовался таким стилем. Сейчас перешёл на java и «египетский» мне кажется гораздо нагляднее. Опять же, Макконел в «Совершенном коде» так ругается:
Хотя такой подход выглядит хорошо, он нарушает Основную теорему форматирования, так как не показывает логическую структуру кода. При таком расположении begin и end не являются частью управляющей структуры, но в то же время, они не являются и частью блока выражений, расположенного далее.
Хотя такой подход выглядит хорошо, он нарушает Основную теорему форматирования, так как не показывает логическую структуру кода. При таком расположении begin и end не являются частью управляющей структуры, но в то же время, они не являются и частью блока выражений, расположенного далее.
C египетскими скобками вижу одну сложность: когда условие if очень длинное и разбивается на несколько строк, часто в коде видишь что-то типа:
if (a && b && c &&
d && e && f) {
blah-blah-blah
}
и как-то сложно понять, особенно если строки длинные, где еще условие, а где уже код. А так это вопрос привычек и личных предпочтений, который в пределах компании решается Code Convention'ами и Style Guide'ами.
if (a && b && c &&
d && e && f) {
blah-blah-blah
}
и как-то сложно понять, особенно если строки длинные, где еще условие, а где уже код. А так это вопрос привычек и личных предпочтений, который в пределах компании решается Code Convention'ами и Style Guide'ами.
обычно это решается двойным отступом при переносе условия:
тоже не очень красиво, но привыкается быстро.
if (a && b && c &&
d && e && f) {
blah-blah-blah
}
тоже не очень красиво, но привыкается быстро.
Когда условие if становится очень длинным, это свидетельствует об том, что пора заняться рефакторингом кода. К примеру провести «выделение метода» или поискать возможность включения граничных операторов, но главное что не писать таких монстров.
Когда условие длинное, лучше сделать так:
bool goodWeather = noRain && noSnow && noWind;
bool goodTemperature = (15 < temperature) && (temperature < 30);
if (goodWeather && goodTemperature) {
// do smth.
}
if( correctCondition() ) {
blah-blah-blah
}
это не проблема
blah-blah-blah
}
это не проблема
А я вообще без скобок пишу :)
def method
#…
end
и очень этому рад :)
def method
#…
end
и очень этому рад :)
Раньше тоже ставил египетские, но потом заметил, что после первой скобки всегда оставляю пустую строку. Т.к. пустые строки немного раздражали, я подумал: а почему бы туда не ставить скобку? Вот так я и стал curly-bracket-on-the-next-line man =)
Больше посмеялся, чем культурно обогатился :)
Из ссылки на стековерфлоу еще понравилось это, весьма точное сравнение:
Ну для языков, где разрешено присваивание в if это еще может иметь смысл, для защиты от опечаток и недопечаток.
Именно потому так и пишут некоторые продвинутые программисты.
Константе значение присвоить не получится, а потому компилятор ругнется, если не будет хватать одного "=".
Константе значение присвоить не получится, а потому компилятор ругнется, если не будет хватать одного "=".
а помоему нынче это уже глупо.
читается именно в йода стиле, а на присваивание в ифе любой приличный компилятор даст ворнинг.
читается именно в йода стиле, а на присваивание в ифе любой приличный компилятор даст ворнинг.
В интерпретируемых языках нет ворнингов. Но всё равно при определённой квалификации программист будет автоматически два раза нажимать на «=» при написании условия.
Да это всегда было глупо. Если человек подразумевает вероятность ошибиться в довольно хорошо различимых объектах (ну разве что «привет, паскалистам»), то что уж говорить про менее тривиальные вещи. Напротив, излишняя концентрация на условиях позволит сделать их более аккуратными, а ведь условные ветки всегда сложнее отлаживать, чем последовательность операторов.
Да, это я знаю. Мне сравнение понравилось :).
Запрет присваивания в if приведёт к хитросплетённому и нелогичному синтаксису. На самом деле это проблема для языков, приводящих всё к int и ожидающих везде int (т.е. C :]).
В D if ожидает boolean, так что if (count = 5) не сработает, а if (b = (count == 5)) — сработает. Или даже if (bool b = count == 5)
В D if ожидает boolean, так что if (count = 5) не сработает, а if (b = (count == 5)) — сработает. Или даже if (bool b = count == 5)
В интерпетируемых динамически-типизированных языках часто идет проверка не на равенство с чем-то, а на непустое значение, при этом нет смысла проверять, что a <> 0, a<>"" и т.п. — для простоты хочется иметь очень простую проверку подходящую для любого типа:
if (a) {}
if (a) {}
И на что это должно проверять, в случае, например, строк? На пустую строку или на null?
На значение, то есть не пустая строка и не нулл.
Пустая строка — не значение, ноль — не число?
Это в общем плане. А в конкретном это выглядит так: если тебе пришло, скажем 0 комментариев, или число комментариев оказалось не задано (что обозначает отсутствие данных), то нужно скрыть блок комментариев.
Если тебе не нравится встроенное приведение к bool, всегда можно проверить на равенство null.
это называется приведение типов, 0 — фолс, -1 — тру, итд… не нравится? == и вперед перечислять что хочешь видеть на самом деле
Без присваивания в if простой код вида
while ((len = read( td, rbuf, 250 ))!= -1){
Превращается в нечто весёлое.
P.S. Да, я любитель египетских скобок :)
while ((len = read( td, rbuf, 250 ))!= -1){
Превращается в нечто весёлое.
P.S. Да, я любитель египетских скобок :)
В PHP иногда пишу что-то вроде
if ($a = $b[$c]) {//Присваивание, а не сравнение
Но в таких случаях всегда стараюсь писать комментарий, что присваивание — это не опечатка.
if ($a = $b[$c]) {//Присваивание, а не сравнение
Но в таких случаях всегда стараюсь писать комментарий, что присваивание — это не опечатка.
а я стараюсь присваивать прям перед ифом во временную переменную, и потом совать ее в иф, для наглядности можно ее сразу же убить после ифа
У. Р. Стивенс в своих книгах исповедует такой вариант:
Смысл в скобках с пробелом в if ( (, которые сразу стопорят взгляд и дают понять что это именно условие с присвоением.
Вариант без присвоения пишется как обычно:
if ( (x = assignment_expression) == value) {
// expression
}
Смысл в скобках с пробелом в if ( (, которые сразу стопорят взгляд и дают понять что это именно условие с присвоением.
Вариант без присвоения пишется как обычно:
if (condition == value) {
// expression
}
Это все юмор от незнания.
Как и выше упомянутые вами «египетские скобки», вполне имеющие право на жизнь, и являющиеся одним из множества стандартов написания кода. Спорить о том, куда лепить скобку, бессмысленно — слишком это мелочно.
А касательно Йоды: вам не нравится, что число перед переменной? Вы просто не в курсе, что это превентивная мера, часто спасающая от ошибки if (count = 5).
Вы еще наверное не в курсе, что в некоторых языках if может быть справа от выполняемого действия? Например, a = 3 if b == 5.
Как и выше упомянутые вами «египетские скобки», вполне имеющие право на жизнь, и являющиеся одним из множества стандартов написания кода. Спорить о том, куда лепить скобку, бессмысленно — слишком это мелочно.
А касательно Йоды: вам не нравится, что число перед переменной? Вы просто не в курсе, что это превентивная мера, часто спасающая от ошибки if (count = 5).
Вы еще наверное не в курсе, что в некоторых языках if может быть справа от выполняемого действия? Например, a = 3 if b == 5.
дело не в нравится/не нравится, никто никого не осуждает. дело в названиях. читай заголовок
Вы невнимательно читаете. Во-первых, я не говорил, что египетские скобочки не имеют права на жизнь — я просто высказал свое отношение к ним. Во-вторых, я уже написал, что я в курсе, зачем константу пишут перед переменной; меня в этой картинке позабавила исключительно точность сравнения.
Как по мне, Йода стайл применим еще в таком случае:
emum Foo{...}
…
if (Foo.FooTheFirst == myVariable)
{
…
}
В таком случае оператор if больше напоминает оператор switch — немного улучшается читаемость. Ну… Это когда switch использовать нельзя. Также применимо для конкретных случаев и является делом вкуса.
emum Foo{...}
…
if (Foo.FooTheFirst == myVariable)
{
…
}
В таком случае оператор if больше напоминает оператор switch — немного улучшается читаемость. Ну… Это когда switch использовать нельзя. Также применимо для конкретных случаев и является делом вкуса.
Речи Йоды тайна раскрыта, старый на Форте программист оказывается он.
у меня почему-то такой стиль в SQL прижился
SELECT * FROM t1 WHERE x=42 AND 0=(SELECT COUNT(*) FROM t2 WHERE t1.a=t2.b)
SELECT * FROM t1 WHERE x=42 AND 0=(SELECT COUNT(*) FROM t2 WHERE t1.a=t2.b)
5 count == if ... else ... thenЙода-стайл, Форт.
такая запись даже является стандратом в некоторых code guidlines, например в симфони для пхп
Настоящие джедаи пишут
if Count = 5 then
if Count = 5 then
Странно, что в топике этого нет, самая крутая тема из того треда на StackOverflow.
Ну как бы в некоторых языках это справедливо. И никакой это не стиль Yoda, а совершенно разумное убирание одних граблей в сторону.
Попробовал в двух основных для себя языках сейчас. Увы и ах )
exp.go:3: z = 3 used as value
>>> if z = 3: print('asd')
File "", line 1
if z = 3: print('asd')
^
SyntaxError: invalid syntax
Попробовал в двух основных для себя языках сейчас. Увы и ах )
exp.go:3: z = 3 used as value
>>> if z = 3: print('asd')
File "", line 1
if z = 3: print('asd')
^
SyntaxError: invalid syntax
Спасибо. Но иногда тонко…
Здорово! Осталось найти ту заразу, которая рассказала про Fear-driven development нескольким моим знакомым ПМам, и ту, которая в проекте, с которым я сейчас работаю, решила использовать String typing… Но по крайней мере, теперь я знаю, как это называется! :-)
Очень ощущается отсутствие художественности перевода. Многие шутки останутся непонятыми.
О да!.. Просто прекрасно!
очень забавная статья получилась, спасибо, улыбнуло.
>>> Тестировщик: Да… пожалуй
Уволил бы такого сразу, нормальный тестировщик использует все пальцы включая даже не пальцы, лишь бы воспроизвести найденный раннее глюк.
Уволил бы такого сразу, нормальный тестировщик использует все пальцы включая даже не пальцы, лишь бы воспроизвести найденный раннее глюк.
Шикарно! Но, к сожалению, увидел много знакомого.
Оказалось, что я все это уже видел :)
Спасибо!
Спасибо!
Пусть пользователи будут тестировщиками <...>
Почти прямая цитата Грега Кроа-Хартмана с Google Tech Days. Грустно.
и почему же грустно?)
вы ни где не получите фидбека кроме как от живых пользователей
и эта фраза не означает давайте выпустим на рынок говно
вы ни где не получите фидбека кроме как от живых пользователей
и эта фраза не означает давайте выпустим на рынок говно
Не очень то и грустно на самом деле. Хоть тестировщики в штате и хорошо, они всего лишь выполняют свою работу. А вот пользователи используют программу. И им всё же зачастую виднее, что сделано не так.
Как по мне, этот подход очень даже подойдет в продуктах без, если можно так выразиться, четко утановленных требований, в результате сложно оценить необходимость добавления или устранения каких-либо «фич». В этом случае пользователи-тестеры помогут как никогда лучше и будет совсем не грустно.
Это называется «путь мягкого ввода», т.е когда цель первыми выпустить продукт (например какой нибудь web-сервис) потому что глюки (если они мелкие) можно отловить и позже, а вот если не успеть с выпуском до того как конкуренты выпустят аналогичный сервис, то убедить пользователей переходить на ваш сервис будет уже труднее…
«Тестировщик: Модуль X не работает корректно
Разработчик: Должно быть раньше вы использовали неправильный палец.
Тестировщик: Да… пожалуй..»
Для владельцев новых айфонов 4G весьма актуально, пожалуй)
Разработчик: Должно быть раньше вы использовали неправильный палец.
Тестировщик: Да… пожалуй..»
Для владельцев новых айфонов 4G весьма актуально, пожалуй)
Паттерн документирования «Буказоид» предлагаю переименовать в «Капитан Очевидность»
Может, "Сепульки"?
Тогда уж так :)
// class comment
/**
* Bukazoid manager is a manager to manage bukazoids.
*/
public class BukazoidManager extends SomeOtherClass { // class definition
...
} // end of class body
> Нажимай сильнее / Неправильный палец / Правильно держи мышку
— Мне нравится мой новый iPhone 4 (отличная работа), но когда я касаюсь рукой металлического канта, сигнал пропадает. Это похоже на распространённую проблему. Есть какие-нибудь планы по её исправлению?
— Просто старайтесь не держать его таким образом
— Мне нравится мой новый iPhone 4 (отличная работа), но когда я касаюсь рукой металлического канта, сигнал пропадает. Это похоже на распространённую проблему. Есть какие-нибудь планы по её исправлению?
— Просто старайтесь не держать его таким образом
РеФАКторинг — чудесный метод!
Что из оригинала еще улыбнуло:
Bloombug
A bug that accidentally generates money (just did this one) — полезно :), но не всегда ненаказуемо.
Из комментариев:
I always thought «excrement» should have been the opposite of increment
Что из оригинала еще улыбнуло:
Bloombug
A bug that accidentally generates money (just did this one) — полезно :), но не всегда ненаказуемо.
Из комментариев:
I always thought «excrement» should have been the opposite of increment
Я всегда открывающую скобку ставлю сразу после функции / условия, следом коротенький однострочный коммент типа того
function blablabla() { // она самая
action;
}
function blablabla() { // она самая
action;
}
Дарвиновское программирование/Экспериментальное программирование
Изменение кода(как правило, случайное) без понимания смысла изменений, пока он не заработает. Например, замена инкремента на декремент.
вот здесь я узнал себя…
Тут, Игорь, многие себя узнали. Просто мало кто в этом признается… :-)
оказывается я не одинока :)
Я так на олимпиадах пишу. Что интересно — иногда срабатывает.
У меня этот метод делится на 2 способа:
1. Куча переменных с непонятными именами, пробовать в каком-нибудь месте поменять одну переменную на другую.
2. О, а если то, что получилось, умножить на 2 и прибавить 18, то мы получим правильный ответ! Так, сделаем еще несколько тестов… Да, так и напишем.
У меня этот метод делится на 2 способа:
1. Куча переменных с непонятными именами, пробовать в каком-нибудь месте поменять одну переменную на другую.
2. О, а если то, что получилось, умножить на 2 и прибавить 18, то мы получим правильный ответ! Так, сделаем еще несколько тестов… Да, так и напишем.
И пусть потом рассказывают, что олимпиадники классные программисты…
При найме для меня это будет некоторым плюсом, но никак не решающим.
При найме для меня это будет некоторым плюсом, но никак не решающим.
Ошибка, подчиняющаяся принципу Гейзенберга — очень ок :)
JFDI(just fucking do it) — методика разработки часто применяемая после срыва сроков
Вчера занимался дарвиновским программированием — нужно было реализовать один алгоритм, который должен был нечто рассчитать, заказчик на вопрос каким образом это нужно рассчитать только мычал в трубку и приводил кучу взаимоисключающих примеров. Пришлось писать фигню и исправлять ее по мере того как заказчик уточнял задание:)
Метод Перкова очень похож на нисходящее программирование Вирта, и оно мне нравится. Просто не надо писать сочинения на тему.
Что-то в статье притянуто за уши, что что-то просто вызывает протест. Например, в разделе «Очень ориентированное программирование(ООП, Over Oriented Programming)» приведена схема синтаксиса языка Javascript. Это самая компактная и наглядная запись спецификации. К ООР она не имеет ну ни малейшего отношения. (больше информации на пример тут blog.nicksieger.com/articles/2006/10/27/visualization-of-rubys-grammar и ещё 1001 месте)
Пинг-понг понравился :) Как раз в тему с айфоном новым)
«TDDD: Technical Debt-Driven Development» переводится как «Разработка управляемая 'техническим долгом'».
То есть, когда разработчик постоянно откладывает фиксы и улучшения в коде «на потом».
То есть, когда разработчик постоянно откладывает фиксы и улучшения в коде «на потом».
«TDDD: Technical Debt-Driven Development
Разработка, управляемая техническими сомнениями»
TDDD: Technical DOUBT-Driven Development ???
Разработка, управляемая техническими сомнениями»
TDDD: Technical DOUBT-Driven Development ???
while (2
Вывели с коллегами IDD- Imagination Driven Development.
Нет документации, нету user story, нету ничего. Только ты, IDE и твое воображение.
Нет документации, нету user story, нету ничего. Только ты, IDE и твое воображение.
Недавно услышал термин «demo-oriented development» — это когда в процессе разработки приходится переодически демонстрировать результаты начальству, и целью становится не работающая программа, а такая, которую «лишь бы продемонстрировать». Часто для этого приходится даже тщательно подбирать последовательность действий, чтобы программа не вылетала и не провалила демонстрацию.
Йооопт! Тащу в блог =))) Это все надо перевести и задокументировать!
— Hydra Code
Code that cannot be fixed. One fix causes two new bugs.
It should be rewritten.
Змей Горыныч =))
Код, который невозможно починить. Каждый фикс порождает 2 новых бага. Нужно переписывать с нуля
— Hydra Code
Code that cannot be fixed. One fix causes two new bugs.
It should be rewritten.
Змей Горыныч =))
Код, который невозможно починить. Каждый фикс порождает 2 новых бага. Нужно переписывать с нуля
Ох, что-то картинка великовата. В качестве извинения — переводы других забавных вещей:
Pokemon Exception Handling — Поймай их всех
Google Code — 5-10 строк кода, найденных после трех часов гугления, которые вы боитесь поменять, т.к. использующийся там API нелогичен и черезмерно сложен.
Loch Ness Monster Bug (Лохнесский баг) — невоспроизводимый баг, который видел только один человек.
Megamoth (MEGA Monolithic meTHod) — Мегамонолитный метод, как правило сидящий внутри Божественного объекта/класса, простирающийся на 2 экрана и более. Были замечены мегамоты высотой в 2000 строк кода =)
Pokemon Exception Handling — Поймай их всех
Google Code — 5-10 строк кода, найденных после трех часов гугления, которые вы боитесь поменять, т.к. использующийся там API нелогичен и черезмерно сложен.
Loch Ness Monster Bug (Лохнесский баг) — невоспроизводимый баг, который видел только один человек.
Megamoth (MEGA Monolithic meTHod) — Мегамонолитный метод, как правило сидящий внутри Божественного объекта/класса, простирающийся на 2 экрана и более. Были замечены мегамоты высотой в 2000 строк кода =)
судя по количеству комментариев про «ебипетские скобки» дальше никто не читал…
Хабраюмор?
Никто не знает, как они такую картинку получили?
И для какого это языка.
И для какого это языка.
По-моему, эта картинка там просто для красоты. Где-то я уже ее видел. И если не изменяет память, это описание того, как в Windows происходит системный вызов. Либо Windows, либо Linux. Их там где-то в сравнение приводили. Давно было дело.
Похоже на творение graphviz'овского dot. А в комментах выше уже сказали, что это схема то-ли лексера, то-ли парсера Javascript'а.
Наши программисты на вопрос — какой ваш любимый паттерн отвечают- паттерн
«костыль»
«костыль»
Мне ещё понравилось:
Yoda condition:
Yoda condition:
if (42 == value) {
// …
}
О Боже! У меня синдром перкова, надо лечиться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Жаргон программистов