Здравствуйте, Sheridan, Вы писали:
>> В опенсорсе здесь просто анархия, держится на честном слове. S>Твои слова держутся на честном слове, извините за каламбур. Не участвовал ты в проектах вестимо...
А что, нужно учавствовать в проекте, дабы увидеть бред, который там вместо кода ?
Здравствуйте, Cyberax, Вы писали:
I>>Только в опенсорсе некто недо может влезть насрать где попало. На конторах обычно есть кодинг-стандарты, код-ревью и всякие пакости другие, которые помогают сохранить чистоту кода, хотя бы отчасти. C>Ты участвовал в достаточно крупных OpenSource-проектах? Правильно, не участвовал.
Не нужно учавствовать, что бы взять да посмотреть исходный код.
C>Так как в большинстве из них это всё есть.
Есть и что ? По моему качество кода в Опенсорсе обычно гораздо хуже, чем в коммерческом.
Hi Ikemefula
>>> В опенсорсе здесь просто анархия, держится на честном слове. S>>Твои слова держутся на честном слове, извините за каламбур. Не участвовал ты в проектах вестимо...
I>А что, нужно учавствовать в проекте, дабы увидеть бред, который там вместо кода ?
Чтобы посмотреть код участвовать не нужно. Но если бы ты поучаствовал в разработке open source продуктов, то чушь, которая выделена жирным ты бы не говорил. Потому что в противном случае получается как уже писали не open source, а trash source.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Cyberax, Вы писали:
I>>>Только в опенсорсе некто недо может влезть насрать где попало. На конторах обычно есть кодинг-стандарты, код-ревью и всякие пакости другие, которые помогают сохранить чистоту кода, хотя бы отчасти. C>>Ты участвовал в достаточно крупных OpenSource-проектах? Правильно, не участвовал.
I>Не нужно учавствовать, что бы взять да посмотреть исходный код.
Ну-ка расскажи, каким образом, посмотрев исходный код, можно "насрать где попало".
C>>Так как в большинстве из них это всё есть.
I>Есть и что ?
Есть и всё. Значит, применяют и соблюдают, и в этом аспекте нет разницы, закрытая разработка или открытая.
I>По моему качество кода в Опенсорсе обычно гораздо хуже, чем в коммерческом.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, IT, Вы писали:
IT>>Это уже не open source, это — trash source. Ни в одном нормальном проекте тебе не дадут гадить просто так.
I>Опенсорсники не считают свой код корявым. Свой код им не кажется непонятным, сложным и тд и тд. В этом все дело.
Прекрасно. А знаешь ли ты, что проприетарщики не считают свой код корявым? Свой код им не кажется непонятным, сложным и тд и тд. В этом все дело.
I>А что, нужно учавствовать в проекте, дабы увидеть бред, который там вместо кода ?
В этом одно из отличий открытой разработки от закрытой. Для того, чтобы увидеть бред, который вместо кода в закрытом проекте, в нем обязательно надо участвовать, а в открытом — можно так посмотреть.
Здравствуйте, Mystic, Вы писали:
M>Да и код зачастую исследовательский: возникает идея и непонятно, принесет она дивиденды или нет. Заранее все педантично оформлять не зватит никакого времени на разработку. Оформлять опосля? Не всегда есть и на это время. M>Далее, такой код зачастую содержит элементы научно исследовательской работы. И находится он должен в виде, наиболее удобной исследователю. А далее разделение труда: исследователь дальше проводит исследования, адепты преобразуют результат его исследований в что-то более академическое. Не всегда эти два качества совмещаются в одном человеке.
Ну вообще-то production код.
M>К тому же ты явно недооцениваешь человеческие возможности. Если человек имеет мотивацию, то человек разберется.
Это непродуктивно.
S>>1. часто нет описания идеи что каждый модуль делает. Ее можно вытащить из кода, но долго
M>В двух словах ее можно вытащить из названия файла.
конечно можно! Разгадать все можно.
Вот доступность и идеи и ее понятность отличает профессионально написанный код от поделки.
S>>2. Минимум комментариев даже для очень нетривиальных методов S>>
s->mtfa[kk] = s->mtfa[s->mtfbase[ii] + jj];
M>Если писать коментарии в таких местах, то весь код будет очень большим коментарием. Разработка раймет в разы больше времени. Выгода? Затрудняюсь ответить. Тут не коментарии нужны, а статья. Общий обзор.
Коментировать нужно не понятные места. Нет извенений, что не хватило времени.
S>>3. Магические констатны смысл которых может вытекать из общей картины, но не из конкретного метода. S>>
if (uc == 0x17) goto endhdr_2;
M>Ну будет там стоять STATE_17, будет проще?
вы ведели код ядра WIndows? Его можно посмотреть в WDK. Там каждый фрагмет прокомментарен, все костанты проименованны со смыслом.
S>>4. Опять макросы, длинные функции по 500 и больше строк
M>Ну длинные функции, что с того?
Это плохо.
M>Так что при разработке проще держать все вместе одним большим замесом.
S>>5. однобуквенные названия переменных (j,i,n,s)
M>Придумай что получше
Я ничего не имею против если щетчик цикла назван i
for( int i=0;i<10; i++ ) do_something();
но если щетчик объявлен 20 строк выше цикла и используется как индекс массива, то его нужно именовать со смыслом
char mydata[ mydatasize ];
int idxMydata=0; // понятно, что индекс для массива mydata
for( idxMydata=0; idxMydata < mydatasize; idxMydata ++ )
mydata[idxMydata]=0;
Очень плохо когда индекс используется несколько раз для разных массивов.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Это сопрограмма. RTFM TAOCP 1.4.2. RO>Алгоритм понимать необязательно, но обрати внимание, как часто вызывается YIELD. С точки зрения программирования, YIELD магическим образом обновляет состояние класса и продолжает выполнение (а на самом деле там return, после которого функция вызывается еще раз с обновленными параметрами).
Код посмотрел и ужаснулся. Ужаснули оба варианта — непонятно ни черта при беглом прочтении, явно требуется в обоих случаях уменьшать уровни вложенности, выделять методы и к выделенным методам писать комментарий. Но вообще, второй вариант мне понравился гораздо больше — там более менее все понятно, особенно если избавиться от волшебных чисел и выделить обработку каждого состояния в отдельный метод (да и от if было бы неплохо избавиться, либо просто непосредственно замапив состояние на его обработчик либо воспользовавшись полиморфизмом и выделив state в отдельный класс). Точнее — второй вариант можно сказать что вообще понравился, замечания у меня мелкие. Хотя, вариант с YIELD вполне имеет право на жизнь, вот только код подструктурировать надо чтоб его понять можно было простым чтением. А в текущей реализации у меня при попытке разобраться в первом варианте начинает голова болеть, если мне такое в рабочем коде встретится я устану черти как уже максимум через 4 часа и дальше уже работать не смогу
И вот теперь стало интересно. Лет 5 назад я бы не ужасался, считал что так и надо писать, восхищался элегантностью решения и умом разработчика и т.д. А сейчас как-то на такое страшно смотреть, понимание, каким должен быть код стало абсолютно другое. Интересно — это что, деградация у меня, или наоборот ? А то — если у кого нахожу из джуниоров такой стиль — дико матерюсь и прошу переписать (или сам переписываю еще более матерясь, если мне там баг приходится править), может я не прав и так и надо писать, а мне уже завязывать пора с программированием ?
E>И вот теперь стало интересно. Лет 5 назад я бы не ужасался, считал что так и надо писать, восхищался элегантностью решения и умом разработчика и т.д. А сейчас как-то на такое страшно смотреть, понимание, каким должен быть код стало абсолютно другое. Интересно — это что, деградация у меня, или наоборот ? А то — если у кого нахожу из джуниоров такой стиль — дико матерюсь и прошу переписать (или сам переписываю еще более матерясь, если мне там баг приходится править), может я не прав и так и надо писать, а мне уже завязывать пора с программированием ?
Сделай так просто, как возможно, но не проще этого.
Здравствуйте, Cyberax, Вы писали:
C>Вполне нормальный код, в общем.
Код конечно ужасным не назову, понять можно не сильно напрягаясь, но можно написать более красиво и понятно, простор для улучшения есть, не идеально . ИМХО
Здравствуйте, shrecher, Вы писали:
M>>Ну будет там стоять STATE_17, будет проще?
S>вы ведели код ядра WIndows? Его можно посмотреть в WDK. Там каждый фрагмет прокомментарен, все костанты проименованны со смыслом.
Скажем, Eclipse SDK тоже вполне хорошо прокомментарен, все константы проименованы со смыслом, и.т.д
Здравствуйте, elmal, Вы писали:
C>>Вполне нормальный код, в общем. E>Код конечно ужасным не назову, понять можно не сильно напрягаясь, но можно написать более красиво и понятно, простор для улучшения есть, не идеально . ИМХО
Ну так напиши... Из всего что я смотрел, в Putty очень простой и понятный код работы с SSL. В OpenSSL он заметно запутаннее.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Maxim S. Shatskih, Вы писали:
С>>>Ты знаком со всем open-source кодом? MSS>>Нет, но с многим. Угребищный стиль кодирования там норма. C>Взял несколько проектов, которые у меня сейчас лежат в виде исходников (кроме ядра Линукса) и взял оттуда наугад кусок кода.
C>1) Cairo — обычный чистый С-шный код, ничего особого.
Нормальный код, форматированный и читаемый. Только не понятно почему надо на С уродоваться, если есть С++.
shrecher однажды (16 июня 2008 [Понедельник] 07:32) писал:
> Нормальный код, форматированный и читаемый. Только не понятно почему надо на С уродоваться, если есть С++.
Наследие у плюсов такое, быть потомком С. Да и С заметно быстрее компилируется, несколько быстрее работает и потребляет меньше памяти...
CreatorCray однажды (16 июня 2008 [Понедельник] 09:27) писал:
> Ну щас чую опять начнется C vs C++
Повоюйте, ага. А я почитаю...
Как раз читаю книжку по истории С++, довольно интересно
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, shrecher, Вы писали:
M>>>Ну будет там стоять STATE_17, будет проще?
S>>вы ведели код ядра WIndows? Его можно посмотреть в WDK. Там каждый фрагмет прокомментарен, все костанты проименованны со смыслом.
WF>Скажем, Eclipse SDK тоже вполне хорошо прокомментарен, все константы проименованы со смыслом, и.т.д
Ну я говорю, что весь код плохой. Просто OSS привлекает новичков и студентов, от этого и качества кода сильно страдает. Нормальный код, это тот, который написан и выложен большими конторами IBM, RH и пр.
Здравствуйте, Сергей, Вы писали:
I>>Не нужно учавствовать, что бы взять да посмотреть исходный код.
С>Ну-ка расскажи, каким образом, посмотрев исходный код, можно "насрать где попало".
Я говорю о том, что в коде уже было насрано до того, как я в него сунул нос.
Так понятно ?
C>>>Так как в большинстве из них это всё есть.
I>>Есть и что ?
С>Есть и всё. Значит, применяют и соблюдают, и в этом аспекте нет разницы, закрытая разработка или открытая.
Разница есть. Многие опенсорсники очень волюнтаристски относятся к исходному коду. Очень часто опенсорс это отсутствие должного контроля над качеством кода.
I>>По моему качество кода в Опенсорсе обычно гораздо хуже, чем в коммерческом. С>Это оно так по твоему, а не на самом деле.
Разумеется, я то говорю о том что видел, в отличие от твоего "на самом деле"
Здравствуйте, Сергей, Вы писали:
IT>>>Это уже не open source, это — trash source. Ни в одном нормальном проекте тебе не дадут гадить просто так.
I>>Опенсорсники не считают свой код корявым. Свой код им не кажется непонятным, сложным и тд и тд. В этом все дело.
С>Прекрасно. А знаешь ли ты, что проприетарщики не считают свой код корявым? Свой код им не кажется непонятным, сложным и тд и тд. В этом все дело.
В коммерческом коде, где одноразовые проекты, все примерно как в опенсорсе.
А вот в более серьезных проектах обычно есть контроль за качеством кода. И здесь девелоперы приучаются писать не для себя одного.
