Примеры «хорошего» кода.

linux kernel.

[имхо] C++ - boost, libpqxx

http://www.google.com/search?q=windows_2000_source_code.zip

linux kernel? хмм. Как мне показалось - там много т.н. хаков.

>http://www.google.com/search?q=windows_2000_source_code.zip

петросян.jpg

Busybox ^_^

> петросян.jpg

С чего бы вдруг? По крайней мере каменты там, насколько я помню, жгут.

>linux kernel? хмм. Как мне показалось - там много т.н. хаков

Например?

Qt

> Восновном интересен C,

хороший код у geany

всё, что в openbsd-tree: http://www.openbsd.org/cgi-bin/man.cgi?query=style

netbsd libc, kernel, base system..

>C++ - boost

бессмысленно говорить про весь boost - он пишется сильно по-разному очень разными программистами

> бессмысленно говорить про весь boost - он пишется сильно по-разному очень разными программистами

Соглашусь, но, скорее потому, что учиться хорошему кодированию на примере любой библиотеки, рассчитаной на работу с различными компиляторами и ОС - крайне неверный путь, если речь идет о C++.

dilmah

Спасибо.

>библиотеки, рассчитаной на работу с различными компиляторами и ОС - крайне неверный путь, если речь идет о C++

а в C++ есть другой путь?

GNU coreutils

Трудно сказать, вероятно, начинать изучение ООП с C++ вообще не самый правильный путь. В качестве примера хорошего ООП-стиля для C++ на вскидку обычно рекомендую API и примеры к Qt. При этом в потроха самой библиотеки лучше на данном этапе не заглядывать.

Qt

> Qt

подтверждаю

> подтверждаю

вы хоть смотрели его?

FVWM

boost?! Если только "от обратного", пример, как писать не надо.

*BSD kernel, base system. nginx, емнип, очень даже неплохо написан. Комментариев бы ему только... 8)) libevent, libdict

Я бы еще обязательно ознакомился с "плохими" проектами. Чтобы знать врага в лицо. Но на самом деле, проектов, где использование неудачных проектных решений (можно даже сказать паттернов) перевешивают хороший стиль кодирования, намного больше нежели проектов, где просто небрежно написан код.

Для примера открой код dovecot. Он написан на си (gnu99). Код аккуратный (хоть и без комментов), но автор использует ООП. Причем, в некоторых местах абсолютно неправильно. Например, драйвер мускуля в src/lib-sql/driver-mysql.c.

OpenBSD код мне очень нравится. И свои проекты я обязательно компилю под этой осью. Пара лишних варнингов не помешает :-)

код ettercap - самый лучший С-код из виденных мной

>> подтверждаю

>вы хоть смотрели его?

а что не так? мне лично очень нравится ещё могу antico привести в пример как легко читаемый (с точки зрения, оформления и комментирования), только не пишите ТАК бездарно

Qt неплохо написан, по крайней мере те части, которые я смотрел, были весьма понятны. Boost вряд ли стоит читать. Там ужасающее количество хаков для совместимости с разными (недо)компиляторами.

> OpenBSD код мне очень нравится. И свои проекты я обязательно компилю под этой осью. Пара лишних варнингов не помешает :-)

А там разве не gcc? откуда тогда лишние ворнинги?

> А там разве не gcc? откуда тогда лишние ворнинги?

Например, вот что пишет линковщик:

/usr/lib/libstdc++.so.47.0: warning: strcpy() is almost always misused, please use strlcpy()
/usr/lib/libstdc++.so.47.0: warning: strcat() is almost always misused, please use strlcat() 

Через gcc'шные атрибуты функций можно форсировать выдачу некоторого кол-ва предупреждений в случае, например, игнорирования возвращаемого значения. Бывает полезно.

аффтар топика - эстет ?
на си нет красивого кода , си - сам по себе сплошной хак

ужасный код на любом языке - это когда в нем нет комментариев
например для любителей qt (3.3.x) - посмотрите на bool QProcess::start( QStringList *env ):
тут и отвратительные define, непонятные QProcessPrivate\QProcessManager, дубли кода, отсутствие комментариев

> ужасный код на любом языке - это когда в нем нет комментариев

Не всегда отсутствие комментариев равно ужасному коду.

> тут и отвратительные define, непонятные QProcessPrivate\QProcessManager, дубли кода, отсутствие комментариев

Где там отвратительные дефайны? Q_OS_QNX4?

Где там отсутствие комментариев?

Вполне понятный код. Не идеал, конечно, но желания убить кодера и тут же переписать функцию не возникает.

Очень хороший Си-код в сорцах PostgreSQL.

про QProcess::start

дефайны отвлекают внимание (мелко раздражают)

было бы неплохо пояснить в коментариях механизм запуска дочернего процесса (зачем делаются те или иные действия)

коментариев нет для QProcessPrivate\QProcessManager - зачем они

непонятное наименование переменной 'd' - фантазии нехватило ?

а вспомнил я этот метод потому, что задумал переписать его для себя - отвязатся от qt :)

> дефайны отвлекают внимание (мелко раздражают) А что делать-то? На том или ином уровне он неизбежно появятся. Писать под каждый вариант отдельную функцию? Тот ещё копипастинг будет... Там разница в пятёрке строк.

> было бы неплохо пояснить в коментариях механизм запуска дочернего процесса (зачем делаются те или иные действия)

Либо я чего-то не понимаю, либо там прокомментировано всё, кроме совсем уж тривиальных и стандартных действий (да то...)

> коментариев нет для QProcessPrivate\QProcessManager - зачем они

Это да. Blackbox как он есть. 8))

> непонятное наименование переменной 'd' - фантазии нехватило ?

Ну называлась бы она private, радости-то... 8))

Я, как бе, не считаю код qt (тем паче трёшки) идеалом с точки зрения внутренностей (хотя достаточно близко к нему, всё-таки)... Вот документированность API заслуживает всяческих похвал, это да.

http://zeroc.com/download.html

> на си нет красивого кода , си - сам по себе сплошной хак

это утверждение основано на личном опыте? :)

> коментариев нет для QProcessPrivate\QProcessManager - зачем они

Для обеспечения бинарной совместимости. http://en.wikipedia.org/wiki/Opaque_pointer Это общеизвестно (по крайней мере, всем, кто пишет крупные библиотеки и не желает выслушивать много крика от пользователей библиотеки при каждой правке кода). Что, в каждом месте комментарий писать? Так оно в каждом классе так сделано в Qt, посмотрите сами.

Понятие хорошего стиля __ОЧЕНЬ__ относительно, т.е. зависит от языка и решаемой задачи.

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

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

Можно выделить объективный критерий хорошего кода -- например, отсутствие дублирования (что помогает пониманию и рефакторингу). Тем не менее, зачастую дублирование происходит, т.к. иначе нельзя. Приходится дублировать абстракции, которые язык *не может* определить в одном месте, и затем использовать в разных.

Ну и каким тогда считать этот код -- хорошим или нет?

З.Ы. Конкретнее (отсылаясь к твоему предыдущему топику): концепция аллокатора в С++ например может сделать твой код malloc/realloc плохим (я бы и покруче сказал). Да и вообще, плюсовый sort инлайнит сравнение элементов.

> linux kernel
не советуй дурного. особенно отжигают многие драйверы.

>> OpenBSD код мне очень нравится. И свои проекты я обязательно компилю под этой осью. Пара лишних варнингов не помешает :-)

> А там разве не gcc? откуда тогда лишние ворнинги?

там _свой_ gcc. со своими ворнингами. а еще libc и _очень_ похаченный malloc, если им выставить максимальные возможности по защите от типичных ошибок программиста, типа buffer overflow, то многие крупные проекты тут же падают, например, файрфокс и гном. то есть, есть возможность легче поймать некоторые баги.

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

(Не совсем в тему)

О крастое кода и культуре программирования вообще есть отличные заметки: http://www.insidecpp.ru/art/

> netbsd libc, kernel, base system..

Не флейма ради - почему не упомянули FreeBSD наряду с Open и Net?

Более-менее приятный код на Си - в исходниках ОС, там, где Си используется по назначению. В т.ч., к примеру, стоит посмотреть утекшие сорцы win2000.

На C++ хорошего кода не видел. Все, что довелось посмотреть(в том числе и Qt, и, тем более, части Boost) - отвратительное нечитаемое и окостылизированное [вещество].

> Не флейма ради - почему не упомянули FreeBSD наряду с Open и Net?
потому что код фришки местами такое же говно, как у линукса.
// сам я смотрел только порты пф и карпа. говорят, так всех новых системах фри еще хуже.