суббота, 27 февраля 2010 г.

[prog.flame] Попытался прочитать книгу “97 Things Every Programmer Should Know”

Издательством O’Reilly была выпущена книга “97 Things Every Programmer Should Know”. Сколько-то там известных (как выяснилось, не для меня) программистов поделилось своими советами – якобы такими вещами, которые обязан знать каждый программист.

Каждый совет – две странички. При таком объеме на каждый совет я ожидал очень конкретных и акцентированных рекомендаций. Вроде очень простого, но весьма действенного совета для C/C++ программистов – в операциях сравнения на равенство всегда слева располагать константу. Т.е. писать if(0==i), а не if(i==0).

Но меня ждало разочарование. Ничего похожего на подобные концентрированные и сугубо практические рецепты не было. Были какие-то банальности вроде “лучше быть здоровым, чем больным, поэтому нужно следить за своим здоровьем” от каких-то неизвестных мне личностей. Временами противоречивые (кто-то советует не модифицировать старый код из соображений его улучшения, кто-то же советует стараться улучшать доставшийся вам в наследство код).

Я прочитал 117 страниц книги (из 257 в моей PDF-ке) и встретил всего три дельных главы – в одной приводились хорошие соображения для форматирования кода (совет от Yechiel Kimchi, стр.30), во второй – совет не писать глупости в комментариях в надежде, что их никто кроме вас не увидит (Cal Evans, стр.32), в третьей – предупреждение о том, что вещественные числа не являются обычными числами (Chuck Allison, стр.66). Мне это показалось слишком слабой концентрацией полезной информации на единицу объема.

12 комментариев:

Ctapmex комментирует...

*пристроился с паяльником*
а что , по твоему мнению, должен знать каждый программист?
-)

Евгений Охотников комментирует...

Не было возможности ответить на выходных, поэтому долго думал :) Но придумать смог лишь очередную банальность.

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

Поэтому, программисту нужно учиться писать хороший код сразу. Никаких поблажек себе в процессе обучения. И в дальнейшем, если возникает соблазн сделать что-то быстро и коряво, то следует себя одергивать. Как правило, если подумать, найдется более качественное решение.

Но, опять же, программа должна работать. Поэтому, если уж никаких других способов нет, то нужно воспользоваться грубой силой (как кто-то сказал: "эффективность brute force еще никто не отменял").

Вот как-то так :)

Ctapmex комментирует...

да, одернуть себя надо еще суметь, заставить. Совет хороший. запомню.
спасибо

Rubanets Myroslav комментирует...

а вот и не надо слева ставить константу ;)
http://www.rsdn.ru/forum/cpp/3713894.1.aspx

не надо крутить левую резьбу и не будет проблем :)

зы программы все еще пишутся для машины. по крайней мере на си/++. Когда джава/шарп/whatever победят жадность кастомеров тогда и наступит коммунизм "правильного кода" "для программистов читателей".

Евгений Охотников комментирует...

>а вот и не надо слева ставить константу ;)
http://www.rsdn.ru/forum/cpp/3713894.1.aspx


Забавно. Не так давно на LOR-е был срач по поводу оптимизации GCC, который вот из подобного кода:

int i = p->i;
if( p == NULL ) return;

выбрасывал строку с if.

>зы программы все еще пишутся для машины. по крайней мере на си/++.

Не согласен. Для C/C++ читабельность и простота кода гораздо важнее, чем для какой-нибудь Java.

>Когда джава/шарп/whatever победят жадность кастомеров тогда и наступит коммунизм "правильного кода" "для программистов читателей".

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

Rubanets Myroslav комментирует...

[prog.flame] обязывает :))

Единственная причина по которой новый проект пишется на плюсах та же что и много лет назад - ассемблер не удобен а выжимать биты из байтов и такты из микросекунд надо :)
Иначе это просто маразм управленцев, которые забыли умереть после прихода си и юникса.
В нашем случае все просто - помимо управленцев есть еще кастомеры типа [NVDA] которым надо с 3мя миллиардами приборов работать обычному инженеру и что еще веселее с 2мя шт - на сравнение и "на обычном железе" (с 128G RAM) :)

вот такое вот имхо.

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

Евгений Охотников комментирует...

Я тоже так пару лет назад думал, когда активно замену C++ искал (но не нашел, к сожалению).

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

А в отношении Java/C# я периодически наблюдаю такую странную штуку -- после перехода на Java у людей какая-то часть мозга отключается (которая за эффективность кода отвечает). В результате не то что биты из байтов, но просто когда вопрос встает о повышении производительности в два-три раза (даже не на порядок), то старый Java проект уже не поддается разгону.

Может во мне C++ный снобизм цветет, но временами кажется, что два-три толковых C++ника тот же самый проект сделали бы лучше, чем 10 средних Java-виста.

А вообще -- пустое это. Мне вот сейчас серьезный проект на плюсах поднимать предстоит. Так что как бы мне ни хотелось Scala в боевых условиях пощупать и почувствовать разницу, сделать это получится разве что при смене работы.

Евгений Охотников комментирует...

>Потому как смотришь на попытки высокоуровневого ++ и слезы наворачиваются. Потому как теряют и гигабайты и секунды а кактус все так же пушист

Увидев сегодня вот это -- template pattern matching -- вынужден признать, что ты прав. При всем уважении к jazzer-у, я бы хотел держаться от таких наворотов подальше :(

Rubanets Myroslav комментирует...

ну в данном случае мы видим что кактус кудряв и для организации статического полиморфного поведения нужно ему делать химзавивку :D
То есть тут то никаких претензий нет - есть микросекунды на выигрыш и не наша вина что язык *иначе* не умеет.
jazzer'у респект. Я против был другого в общем-то.

Евгений Охотников комментирует...

>Я против был другого в общем-то.

Против чего тогда?

Andrey комментирует...

>но временами кажется, что два-три толковых C++ника тот же самый проект сделали бы лучше, чем 10 средних Java-виста.

Удивительная фраза) Поменяйте местами языки в предложении, и смысл не изменится. Да тут вообще можно подставить любую пару нормальных языков.

Евгений Охотников комментирует...

2Andrey:

>Поменяйте местами языки в предложении, и смысл не изменится. Да тут вообще можно подставить любую пару нормальных языков.

Ага, так и есть. Хорошие программисты пишут хорошие программы на любом языке. Проблема только в том, что чем безопаснее язык, тем проще на нем работать посредственным программистам. Плохой код на C++ == неработающий проект. Плохой код на Java == кое-как работающий проект. К сожалению, сейчас этого часто достаточно.