Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 241
Последний пункт опроса — это такой хитрый прием определения процента быдлокодеров? =)
Именно
Почему не поставили пункт «Я горжусь своим плохим кодом»?
Вот я совсем не программист и написал несколько раз ужасный код. Я настолько не программист, что даже не могу понять насколько он ужасен.
Но все равно горжусь тем фактом, что моя программа не просто работала, а служила людям лет 7.
Вот я совсем не программист и написал несколько раз ужасный код. Я настолько не программист, что даже не могу понять насколько он ужасен.
Но все равно горжусь тем фактом, что моя программа не просто работала, а служила людям лет 7.
Последний пункт опроса — это, скорее, определение процента наиболее опытных программистов, которые иронически ухмыльнутся максимализму подрастающего поколения.
«Нейтрально», имхо — самая адекватная реакция когда тебе указывают на плохой код. Спокойно принял к сведению и перестал так писать. Не головой же биться о стену
«перестал так писать»? )
прикольно…
прикольно…
Поддерживаю. Для хорошего программиста любой законченный модуль морально устаревает на момент релиза.
у меня знакомый есть, который позицоионирует себя аццким программистом, отцом прямо, а меня называет дураком и неумехой. И вот, однажды, я попросил его. Говорю, покажи мне свой код, мне интересно, как пишут отцы? Он говорит — плати тыщщу баксов, и я тебе покажу.
Я ему — зачем мне весь твой код, мне хватило бы всего пары классов.
Он — так пара классов работать то не будет!
Я ему — да я и не собираюсь их запускать, я просто хочу посмотреть как пишут хорошие, аццкие программисты.
На что он ответил — тыщща баксов в месяц, и он научит меня так кодить, мол научит меня нарабатывать свой опыт самостоятельно, а то я якобы этого не умею.
В итоге все свелось как всегда к писькомереву, в котоорм я принял довольно нейтральную позицию.
Да, мой код не идеален, и я при возможности пытаюсь его переписать с учетом моего текущего опыта, и да, я не стыжусь показывать свой код. Проголосовал за 1 пункт)
Я ему — зачем мне весь твой код, мне хватило бы всего пары классов.
Он — так пара классов работать то не будет!
Я ему — да я и не собираюсь их запускать, я просто хочу посмотреть как пишут хорошие, аццкие программисты.
На что он ответил — тыщща баксов в месяц, и он научит меня так кодить, мол научит меня нарабатывать свой опыт самостоятельно, а то я якобы этого не умею.
В итоге все свелось как всегда к писькомереву, в котоорм я принял довольно нейтральную позицию.
Да, мой код не идеален, и я при возможности пытаюсь его переписать с учетом моего текущего опыта, и да, я не стыжусь показывать свой код. Проголосовал за 1 пункт)
и да, он считает плохим тоном постоянное чтение документации к ЯП.
Это правда плохо?
Это правда плохо?
Настоящие админы маны не читают.
Настоящие админы маны уже прочитали.
Настоящие админы маны уже прочитали.
А где работает этот ваш знакомый? как то вы по тролльски описали его, по вашему описанию выходит что этот ваш знакомый — просто квинтэссенция заносчивого и наглого ламера.
Просто школоло наконец-то научилось держать в руках Visual Studio >2008 и пошло отрабатывать «диплом».
да не важно)
он для меня раньше, что то вроде авторитетного человека был, но вот после этого разговора я решил пересмотреть свое отношение к нему)
он для меня раньше, что то вроде авторитетного человека был, но вот после этого разговора я решил пересмотреть свое отношение к нему)
Мне — нейтрально. Все мы когда-то начинали учиться и делали глупые ошибки. Но не думаю, что стоит убиваться по этому поводу. Главное — не повторять их в будущем. Никто не родился аццким кодером.
В коде Чака Норриса никогда не бывает багов. Он никогда не ошибается. Если вы нашли баг в коде Чака — попробуйте поговорить с ним об этом — сразу поймете, что это на самом деле необходимая фича проекта.
habrahabr.ru/blogs/tdd/116514/
habrahabr.ru/blogs/tdd/116514/
начнём с того, что это не опрос, а утверждение
Зачем чекбоксы?
А почему мне должно быть стыдно за плохой код, в котором я сам лично хорошо разбираюсь даже через пол года после его написания?
А кто вам сказал что вам должно быть стыдно? Это опрос, а не поучения о том что вам должно быть стыдно.
Я расцениваю этот опрос именно как вопрос к каждому программисту. Стыдно ли ему за свой плохой код?
Простите что не предусмотрел вариант для вас 'Я горжусь свом плохим кодом', в следующий раз обязательно учту.
«Следующий раз» может нахватать минусов, а ссылка в первом комментарии будет вести сюда :)
А кто считает код плохим, я или вы?
Простите что не предусмотрел вариант для вас 'Я горжусь свом плохим кодом', в следующий раз обязательно учту.
Вообще-то обязательно должен быть такой вариант. Я смотрю на свой код через полгода после начала обучения программирования и понимаю, что у него есть архитектурные изьяны, множесто некорректных, нелогичных или неправильных решений, но задача решена, во всём коде я придерживался одного стиля, старался делать какую-то архитектуру, повторяющиеся блоки кода выносил в функции, развивался и даже умудрялся поддерживать
Да, сейчас я пишу намного лучше и если бы я такой код писал сейчас, то мне было бы стыдно, но то, что я такой код писал через полгода обучения — я горжусь.
Инженеры ВАЗ: «Почему нам должно быть стыдно за наши машины — у них же по-прежнему четыре колеса, даже через полгода их сборки?»
… они по прежнему на ходу даже через пол года, после их сборки и покупки
не факт:)
Я к тому, что если проект подразумевает развитие, то надо делать его хорошо
Я к тому, что если проект подразумевает развитие, то надо делать его хорошо
развитие, пока мне за это платят, а что будет после меня в этом проекте, меня не должно волновать.
Ну тогда вы как ни странно эгоист которому нужны только деньги и вы не хотите совершенствовать свои знания в области программирования
Существует такое понятие как «репутация». Нет?
А как же рекомендации?
… после их покупки и сборки
Потому что Вы пишете код не для себя, не для компилятора, а для людей. Для людей, которые будут в дальнейшем с ним работать. С большой долей вероятности Вы не будете его вечно поддерживать, и когда-нибудь эта обязанность перейдет к другому человеку.
Впрочем, это, конечно, зависит от специфики проекта, но в общем случае одни люди уходят — на их место приходят другие.
Впрочем, это, конечно, зависит от специфики проекта, но в общем случае одни люди уходят — на их место приходят другие.
я пишу код ради его конечной цели, которую желает видеть работодатель. И мне совершенно не интересны следующие после меня работники, которые сядут за модификацию этого кода. Мне за это не доплачивают. Обидно, неприятно, но это действительно так.
это называется эгоизм :)
Любую работу нужно делать хорошо. Вопрос сколько вы получаете или нет за эту работу плохой аргумент.
Вам за это не доплачивают, а платят. Работодатель по-умолчанию желает получить код, который можно будет в дальнейшем поддерживать с минимальными затратами. Если же ему достаточно «чтобы работало и подешевле» — так и скажите ему, что из [«быстро», «дешево», «качественно»] можно выбрать только 2 пункта.
Впрочем, это всего лишь мое мнение, и я не хочу навязывать его Вам. Но на месте потенциального работодателя я бы не стал с Вами связываться.
Впрочем, это всего лишь мое мнение, и я не хочу навязывать его Вам. Но на месте потенциального работодателя я бы не стал с Вами связываться.
скорее все работодатели хотят быстро, дешево и чтоб работало, а что там внутри никого не волнует. Мржет и есть такие мифические работодатели, которых вы описываете, но я таких не встречал.
Нельзя научиться писать хороший код, занимаясь написанием плохого. Вы это для себя должны делать, а не для работадателя, работодателю и правда часто пофиг. Писать хороший код — совсем не сложно ведь, когда привычка выработана и опыт есть. А привычку не выработать, и опыт не получить, занимаясь исключительно интересами работодателя и просто выполняя формально его хотелки. Лучше ведь всегда учиться чему-то, а не просиживать штаны и тратить свое время впустую на удовлетворение чужих интересов. Если писать плохой код, то у работадателя остается работающий продукт (будем считать, что это так), а у программиста не остается ничего. Если писать хороший код, то у работодателя остается работающий продукт (вероятно, работающий чуть лучше), а у программиста — ценный опыт и навыки. Всем ведь хорошо от этого, зачем же тогда ерундой страдать и делать что-то спустя рукава, зачем свое время просто вникуда выкидывать?
полностью с вами согласен, виртуальный плюсик вам в карму. С каждым новым проектом растет опыт, делаешь все лучше и лучше уже на автомате. Но за бесплатно возвращаться к полугодовалым проектам, которые я не веду и что-то то там допиливать бесплатно я никогда не буду. Уж простите меня будущие программисты, столкнувшиеся с моим кодом. =)
Хотел спросить — а где бы найти примеры реально хорошего кода сложных систем? Теория-теорией, а практику можно набивать или на своих пробах и ошибках, или (отчасти) на чужих. Лазил по sourceforge, codeplex и иже с ними — очень тяжело найти хоть что-то с хорошим кодом, в топе зачастую висит вообще адский мрак (напр. farseer physics на codeplex). Желательно для платформы .net.
>примеры реально хорошего кода сложных систем?
git.kernel.org. без шуток.
git.kernel.org. без шуток.
Можно привести конкретный проект? Т.к. далеко не все, что там есть — имеет сколько нибудь хороший код.
Пробежался еще раз по репозиторию — открыл 5 наугад взятых проектов, во всех дочитывал до второго-третьего goto и закрывал. Так что похоже не без шуток (или это очень злые шутки).
В системном програмированние как бы ни говорили туго без GOTO, все таки иногда абстракция блоков кода не так хороша.
Где здесь необходимость в использовании goto?
void sctp_generate_proto_unreach_event(unsigned long data)
{
struct sctp_transport *transport = (struct sctp_transport *) data;
struct sctp_association *asoc = transport->asoc;
sctp_bh_lock_sock(asoc->base.sk);
if (sock_owned_by_user(asoc->base.sk)) {
SCTP_DEBUG_PRINTK("%s:Sock is busy.\n", __func__);
/* Try again later. */
if (!mod_timer(&transport->proto_unreach_timer,
jiffies + (HZ/20)))
sctp_association_hold(asoc);
goto out_unlock;
}
/* Is this structure just waiting around for us to actually
* get destroyed?
*/
if (asoc->base.dead)
goto out_unlock;
sctp_do_sm(SCTP_EVENT_T_OTHER,
SCTP_ST_OTHER(SCTP_EVENT_ICMP_PROTO_UNREACH),
asoc->state, asoc->ep, asoc, transport, GFP_ATOMIC);
out_unlock:
sctp_bh_unlock_sock(asoc->base.sk);
sctp_association_put(asoc);
}
А вы попробуйте сейчас без GOTO написать и поймете.
if (something)
{
// doWorkForSomething
goto end;
}
if (somethingAnother)
{
// doWorkForSomethingAnother
goto end
}
//doSomeWork
end:
// doEndWork
Сорри, отправилось раньше:
На входе имеем:
Без goto
На входе имеем:
if (something)
{
// doWorkForSomething
goto end;
}
if (somethingAnother)
{
// doWorkForSomethingAnother
goto end
}
//doSomeWork
end:
// doEndWork
Без goto
if (something)
{
// doWorkForSomething
}
else if (somethingAnother)
{
// doWorkForSomethingAnother
}
else
{
// doSomeWork
}
// doEndWork
Это был очередной синтетический показатель убогости GOTO, а вот тот код вы можете написать элегантно без GOTO?
А чем тот код отличается от того, что я написал? Просто вместо кусков внутри if'ов того кода вставил комментарии, чтобы было наглядно и не стелить простыню кода.
Ок, пишу приблизительно то, как должен выглядеть код:
Да чтож такое, опять автоотправление)
Тут кроме goto еще куча огрехов, типа залезания в кишки к Base из этой функции, непонятные сокращения, куча параметров у функций и т.д.
т.к. я не разбирался в том, что реально значат сокращения — то мог где-нибудь ошибиться, но это не меняет сути.
Тут кроме goto еще куча огрехов, типа залезания в кишки к Base из этой функции, непонятные сокращения, куча параметров у функций и т.д.
т.к. я не разбирался в том, что реально значат сокращения — то мог где-нибудь ошибиться, но это не меняет сути.
void SctpGenerateProtoUnreachEvent(unsigned long data)
{
struct SctpTransport *transport = (struct SctpTransport *) data;
struct SctpAssociation *stcpAssociation = transport->Asociation;
SctpBhLockSock(stcpAssociation->Base.Sk);
if (SockOwnedByUser(stcpAssociation->Base.Sk))
{
SCTP_DEBUG_PRINTK("%s:Sock is busy.\n", __func__);
// Try again later.
if (! ModTimer(&transport->ProtoUnreachTimer, jiffies + someConst))
{
SctpAssociationHold(asoc);
}
}
else if (!(sctpAssociation->Base.Dead)) // Is this structure just waiting around for us to actually get destroyed?
{
auto sctpStOther = SCTP_ST_OTHER(SCTP_EVENT_ICMP_PROTO_UNREACH);
SctpDoSm(SCTP_EVENT_T_OTHER, sctpStOther, asoc, transport, GFP_ATOMIC);
}
SctpBhUnlockSock(stcpAssociation->Base.Sk);
SctpAssociation_put(stcpAssociation);
}
это хуже читается. основной код уехал на один уровнь вложенности и теперь непонятно, что эта функция делает кроме каких-то проверок.
если же функция аллоцирует не один ресурс, а штук пять, то с таким подходом основной код функции будет на пятом уровне вложенности, его будет трудно сразу увидеть за мешаниной проверок.
или в секции освобождения ресурсов будет пять симметричных проверок для пяти флагов состояний.
флаги состояний — это лишнее обращение к памяти и лишнее место на стеке там, где можно было сразу сделать один BL (jump) в нужную точку.
если же функция аллоцирует не один ресурс, а штук пять, то с таким подходом основной код функции будет на пятом уровне вложенности, его будет трудно сразу увидеть за мешаниной проверок.
или в секции освобождения ресурсов будет пять симметричных проверок для пяти флагов состояний.
флаги состояний — это лишнее обращение к памяти и лишнее место на стеке там, где можно было сразу сделать один BL (jump) в нужную точку.
Еще раз повторю — что проблема в том числе в архитектуре, т.к. многие вещи должно вынести в отдельные функции, тогда и вложенность будет 1-2 уровня и код будет читабелен, и функции не будут простынками на 1000 строчек. Освобождение ресурсов тоже будет простым и понятным.
А уж экономить байт памяти и такты процессора (у нас же компилятор ничего не оптимизирует, или все же оптимизирует?;)) — это уже просто возврат в 80е года. Сейчас о таком можно говорить разве что в жестком embedded.
А уж экономить байт памяти и такты процессора (у нас же компилятор ничего не оптимизирует, или все же оптимизирует?;)) — это уже просто возврат в 80е года. Сейчас о таком можно говорить разве что в жестком embedded.
А чем плох «goto» кроме того, что «люди говорят, что goto — плохо»? Никогда не приходилось им пользоваться, но я реально не могу понять. И я реально не могу понять, почему некоторые считают, что «извернуться через while-break» — это лучше, чем использовать goto.
goto begin
label1: что зачастую очень сильно goto label2
label3: прыгнуть сразу в любую точку функции.
begin: Goto плохо тем (goto label1)
label2: запутывает понимание кода, позволяя goto label3
Если по серьезному, то костыли через while-break ничуть не лучше, если в коде появляются такие костыли или goto — это говорит о том, что сам код организован неправильно. Зачастую там, где убирание goto приводит к увеличения уровня вложенности, или необходимости кучи дополнительных костылей — присутствуют более фундаментальные баги, а goto в этом случае — только симптом. Например зачастую такие функции имеют сотни строк длины, в них идет обращение через 3-4 уровня абстракции и т.д.
В случае же, когда функция сама по себе без «smell», то в ней и не будет аргументированного goto, т.к. она будет выполняться линейно.
Даже в случае отработки cleanup по goto в конце метода гораздо проще ошибиться, чем при аккуратном разбиении этого метода и очистки ресурсов без goto. (например — добавить новую ветку и в ней забыть сделать goto, чего не получится сделать при более безопасных методах организации кода).
label1: что зачастую очень сильно goto label2
label3: прыгнуть сразу в любую точку функции.
begin: Goto плохо тем (goto label1)
label2: запутывает понимание кода, позволяя goto label3
Если по серьезному, то костыли через while-break ничуть не лучше, если в коде появляются такие костыли или goto — это говорит о том, что сам код организован неправильно. Зачастую там, где убирание goto приводит к увеличения уровня вложенности, или необходимости кучи дополнительных костылей — присутствуют более фундаментальные баги, а goto в этом случае — только симптом. Например зачастую такие функции имеют сотни строк длины, в них идет обращение через 3-4 уровня абстракции и т.д.
В случае же, когда функция сама по себе без «smell», то в ней и не будет аргументированного goto, т.к. она будет выполняться линейно.
Даже в случае отработки cleanup по goto в конце метода гораздо проще ошибиться, чем при аккуратном разбиении этого метода и очистки ресурсов без goto. (например — добавить новую ветку и в ней забыть сделать goto, чего не получится сделать при более безопасных методах организации кода).
int Foo_bar(
Foo *f)
{
Boo *b;
Moo *m
b = Boo_new();
if (b == NULL)
{
return MY_ERR;
}
m = Moo_new();
if (m == NULL)
{
Boo_free(b);
return MY_ERR;
}
if (Foo_baz(f, b, m) != MY_OK)
{
Moo_free(m);
Boo_free(b);
return MY_ERR;
}
return MY_OK;
}
Не?
Foo *f)
{
Boo *b;
Moo *m
b = Boo_new();
if (b == NULL)
{
return MY_ERR;
}
m = Moo_new();
if (m == NULL)
{
Boo_free(b);
return MY_ERR;
}
if (Foo_baz(f, b, m) != MY_OK)
{
Moo_free(m);
Boo_free(b);
return MY_ERR;
}
return MY_OK;
}
Не?
Ну например так (далеко не идеал, первое что пришло в голову)
При этом при выделении ресурса первой строчкой стоит проверка выходного result и возврат, если он false, тоже самое в cleanup с проверкой на null.
int Foo_bar(Foo *f)
{
auto status = MY_ERR;
auto b = Boo_new(&result);
auto m = Moo_new(&result);
auto fooBazStatus = Foo_baz(f, b, m);
if (fooBazStatus == MY_OK)
{
status = MY_OK;
}
Moo_free(m);
Boo_free(b);
return status;
}
При этом при выделении ресурса первой строчкой стоит проверка выходного result и возврат, если он false, тоже самое в cleanup с проверкой на null.
Имхо, тут нельзя гарантировать, что Foo_baz не скрэшится, если в него затолкать нуллы в b и m.
Я пояснил снизу, что надо добавить две строки в методы работы с ресурсами, чтобы они проверяли входные параметры. Раз уж она возвращает статус — то пусть просто вернет ERROR.
Видимо, время сказывается, т.к. в Вашем сообщении не было ни одного слова «входной», ну да ладно, тут я с Вам полностью согласен и сам всегда проверяю входные параметры в методах, однако, это могут быть методы, которые мы (или не мы) не можем изменить, скомпиленная либа, например.
И опять же возвращаемся к тому, что если уж выпиливать косяки в архитектуре и не только, то выпиливать их везде, а не в одном методе.
И опять же возвращаемся к тому, что если уж выпиливать косяки в архитектуре и не только, то выпиливать их везде, а не в одном методе.
Когда я что-то пишу — обычно абстрагируюсь от предоставленного API, так потом гораздо легче что-то править.
Что касается модификации уже существующего кода — то тут действительно зачастую удобнее вставить костыль, чем переписывать, т.к. к таким костылям разработчики решения скорее всего привыкли, а переписывание всего займет кучу времени и денег.
Я в основном имею ввиду новые проекты.
Что касается модификации уже существующего кода — то тут действительно зачастую удобнее вставить костыль, чем переписывать, т.к. к таким костылям разработчики решения скорее всего привыкли, а переписывание всего займет кучу времени и денег.
Я в основном имею ввиду новые проекты.
Кстати говоря, в примерах, которые я приводил в замен goto — проще сделать статический анализ кода на предмет бранчей, гарантированно вызывающих ошибки, с goto же такой анализ производить труднее.
>многие вещи должно вынести в отдельные функции
тогда он как раз будет хуже читаться.
>компилятор ничего не оптимизирует, или все же оптимизирует?
нифига он тут не соптимизирует. переставайте верить в магию и начинайте проверять свои мысли листингами дизассемблера.
если писать код ногами, комрилятор не спасет.
тогда он как раз будет хуже читаться.
>компилятор ничего не оптимизирует, или все же оптимизирует?
нифига он тут не соптимизирует. переставайте верить в магию и начинайте проверять свои мысли листингами дизассемблера.
если писать код ногами, комрилятор не спасет.
Ну если вас устраивают листинги кода по 200-500 строк на функцию — пожалуйста, к счастью мы работаем в разных сферах и мне никогда не придется иметь дело с вашим кодом.
У меня интеловский компилер оптимизирует и инлайнит все что можно, но даже там, где он не сможет соптимизировать — это потеря считанных байт-килобайт и наносекунд, для меня гораздо важнее качество кода, чем мифические килобайты и наносекунды.
У меня интеловский компилер оптимизирует и инлайнит все что можно, но даже там, где он не сможет соптимизировать — это потеря считанных байт-килобайт и наносекунд, для меня гораздо важнее качество кода, чем мифические килобайты и наносекунды.
>листинги кода по 200-500 строк на функцию
не фантазируйте.
тем более, что с goto как раз код будет короче.
и функция в 200 строк действительно бывает лучше 300, но размазанных хрен знает где.
не фантазируйте.
тем более, что с goto как раз код будет короче.
и функция в 200 строк действительно бывает лучше 300, но размазанных хрен знает где.
>У меня интеловский компилер оптимизирует и инлайнит все что можно
у меня нет под рукой интелевого, проверял на последнем армовом gc
>потеря считанных байт-килобайт и наносекунд
это запросто может стать ботлнеком
>важнее качество кода
с использованием goto получается как раз качественный, компактный и хорошо читаемый код.
у меня нет под рукой интелевого, проверял на последнем армовом gc
>потеря считанных байт-килобайт и наносекунд
это запросто может стать ботлнеком
>важнее качество кода
с использованием goto получается как раз качественный, компактный и хорошо читаемый код.
Обсуждалось это всё уже по 100 раз. Конкретно тут Вы правы, но вот представьте вложенность не 1-уровневую, а трех-четырех, да пару циклов вложенных, уже изнутри которых и делается goto. В этом случае не обойтись без кучи флагов или дублирования кода. Или goto к месту очистки ресурсов. А коли уж в одном месте проекта так сделали, то и в остальных (даже таких тривиальных как Ваш пример) решили иметь схожее поведения. Ради единообразия.
Так здесь проблема в кривой архитектуре, которая жить не может без goto.
При чем тут архитектура? Куча алгоритмов на графах, матрицах и массивах предполагают двойную-тройную вложенность циклов. Если из внутренних циклов (да еще и из нескольких разных мест) нужно выйти на самый верх и после этого очистить ресурсы — вот вам и пример goto. У Макконнелла по этому поводу целый раздел в «Совершенном коде» есть.
А что мешает использовать функции вместо чудовищной вложенности?
Например, когда алгоритм бегает по строкам:
bool success = true;
for(uint row = 0; row < matrix.RowsCount, row++)
{
success &= ProcessRow(matrix.Row[row]);
if (!success)
{
break;
}
}
return success;
Некоторые вообще сейчас пишут подобные вещи в стиле LINQ, тут конечно на любителя синтаксис, за пару недель привыкается и читается на ура. Главный плюс — возможность очень и очень просто распараллелить все это дело, и включать-отключать параллелизацию централизованно, изменением одной переменной:
private static bool ProcessMatrix(Matrix matrix)
{
var success = Enumerable.Range(0, matrix.RowsCount)
.AsParallel()
.WithDegreeOfParallelism(parallelismDegree)
.All(x => ProcessRow(matrix.Row[x]));
return success;
}
Фы сами только что использовали флаг
чем break лучше goto?
Очнитесь уже, break и goto это одно и то же.
Кстати на хабре была хорошая статья про goto, почитайте:
habrahabr.ru/blogs/cpp/114211/
Очнитесь уже, break и goto это одно и то же.
Кстати на хабре была хорошая статья про goto, почитайте:
habrahabr.ru/blogs/cpp/114211/
Ну и более того — почему кто-то делит ХЗ на 20? И почему на 20? Уж такой то магии в коде не должно быть.
очень хороший и правильный код. goto в конец функции для освобеждения ресурсов при ошибке — общепринятая практика в системном программировании.
просто воспринимайте это как блок try-catch-finally.
просто воспринимайте это как блок try-catch-finally.
препод в пту сказал, что goto — плохо и вы ему поверили, да?
И как с вами можно разговаривать, когда вы даже конструктивную беседу вести не можете, переходя на оскорбления? Пишите с goto, сколько вам угодно, только не надо выдавать свое мнение о прекрасном коде за общую истину, тем более что мнение это непопулярно.
>конструктивную беседу вести не можете,
какая конструктивная беседа с человеком, который не знает о сложившихся практиках системного программирования и о том, что вообще живет на kernel.org?
> мнение это непопулярно.
вы издеваетесь? неполпулярное?
восемьдесятчетые тысячи случаев использования в отраслеобразующем проекте с адским процессом ревью кода.
какая конструктивная беседа с человеком, который не знает о сложившихся практиках системного программирования и о том, что вообще живет на kernel.org?
> мнение это непопулярно.
вы издеваетесь? неполпулярное?
% grep goto kernel -rn | wc -l 84048
восемьдесятчетые тысячи случаев использования в отраслеобразующем проекте с адским процессом ревью кода.
Начнем с того, что я спрашивал источник совершенно не по системному программированию, это раз.
Сложившиеся практики тут — это такой же миф, как выбор единственно правильной нотации именования и расстановки скобочек, в каждой компании он может быть свой.
Три — Греп по этим сорцам мало что показывает, кроме того, что там есть 84 тысячи goto.
Четыре — это какую отрасль образует этот проект? Там же вроде подавляющая часть касается линукса, а это далеко не 100% системного программирования.
Сложившиеся практики тут — это такой же миф, как выбор единственно правильной нотации именования и расстановки скобочек, в каждой компании он может быть свой.
Три — Греп по этим сорцам мало что показывает, кроме того, что там есть 84 тысячи goto.
Четыре — это какую отрасль образует этот проект? Там же вроде подавляющая часть касается линукса, а это далеко не 100% системного программирования.
>в каждой компании он может быть свой.
если использование goto и испльзование кучи вложенных условий и флагов взаимозаменяемы и являются частью привычки так же, как и style guide, то из этого следует как раз обратное — использование goto не может считаться плохим кодом.
еще раз пишу — goto в функциях инициализации — это не замена условиям, а некий аналог try-catch-finally.
более того, конечно такой подход практикуется не только в линуксе.
>Три — Греп по этим сорцам мало что показывает, кроме того, что там есть 84 тысячи goto.
как вы догадались, не читайте моимыслиманы!? конечно он показывает количество goto в коде.
>Четыре — это какую отрасль образует этот проект?
ядро линукса — отраслеобразующий проект для IT в целом. без него мир рухнет.
если использование goto и испльзование кучи вложенных условий и флагов взаимозаменяемы и являются частью привычки так же, как и style guide, то из этого следует как раз обратное — использование goto не может считаться плохим кодом.
еще раз пишу — goto в функциях инициализации — это не замена условиям, а некий аналог try-catch-finally.
более того, конечно такой подход практикуется не только в линуксе.
>Три — Греп по этим сорцам мало что показывает, кроме того, что там есть 84 тысячи goto.
как вы догадались, не читайте мои
>Четыре — это какую отрасль образует этот проект?
ядро линукса — отраслеобразующий проект для IT в целом. без него мир рухнет.
>Нельзя научиться писать хороший код, занимаясь написанием плохого
Нельзя научиться писать хороший код, НЕ занимаясь написанием плохого.
Нельзя научиться писать хороший код, НЕ занимаясь написанием плохого.
Ага, и это верно) Имелось в виду, что человек в данный конкретный момент может написать что-то получше, а может полениться думать и оттого написать похуже (не факт, кстати, что быстрее). В первом случае он узнает больше о проблеме и получит опыт (даже если выяснится потом, что его решение было неверным), во втором — не получит ничего. Ну и примерно те же рассуждения для более длинных промежутков времени.
Плохой и хороший — все равно ведь понятия относительные. Если не знаешь, что улучшить в своем коде годичной давности, то это уже повод задуматься, а не зря ли год прошел.
Плохой и хороший — все равно ведь понятия относительные. Если не знаешь, что улучшить в своем коде годичной давности, то это уже повод задуматься, а не зря ли год прошел.
Спрашивал не раз — большинство хотят как можно быстрее реализовать нужную им функциональность. В лучшем случае ограничивают бюджет не ограничивая (в разумных пределах) срок, но писать качественный код за оплату меньшую чем прожиточный минимум как-то не хочется.
Лучше не делай, если сделаеш плохо.
Совсем не стыдно, но очень хочется переписать.
Очень стыдно. Прямо сейчас переделываю свое «творчество» двухлетней давности.
Если делаю для решения каких-то своих небольших задач, то не стыдно, лишь бы быстро сделалось и работало как надо. А если для кого-то, а уж тем более за вознаграждение, то, конечно, стыд берет свое за плохой код.
Осознание проблемы — верный путь к ее решению. Если человек способен осознать, что он написал плохой код, значит потенциально, он знает почему он таким получился, возможно исправит, а возможно не будет повторять своих ошибок в будущем.
как ни странно, очевидный говнокод я никогда не писал, всегда было чувство стиля и времени на рефакторинг.
да, конечно есть неоптимальные решения, не особо красивые, хаки, но всегда это было в меру — не более какого-то небольшого процента от кода.
есть за которые стыдно, но на большинство — нейтрально.
так что чекбоксы мне пригодились :)
да, конечно есть неоптимальные решения, не особо красивые, хаки, но всегда это было в меру — не более какого-то небольшого процента от кода.
есть за которые стыдно, но на большинство — нейтрально.
так что чекбоксы мне пригодились :)
Покажите свой самый первый код, попавший в продакшн :)
Не верю! Все начинают с плохого кода.
Первый код я написал на листочке тетрадки после прочтения начальных глав книги по какому-то бэйсику. Посколько главы покрывали только ввод-вывод и ветвления, то код получился у меня ну очень интересный (а писал я какой-то тест). Жаль, что листок не сохранился, но выражение лица того программиста, которому я этот код гордо показал я запомнил на всю жизнь.
P.S. Это было в начальной школе и компьютера у меня не было вообще никакого.
Первый код я написал на листочке тетрадки после прочтения начальных глав книги по какому-то бэйсику. Посколько главы покрывали только ввод-вывод и ветвления, то код получился у меня ну очень интересный (а писал я какой-то тест). Жаль, что листок не сохранился, но выражение лица того программиста, которому я этот код гордо показал я запомнил на всю жизнь.
P.S. Это было в начальной школе и компьютера у меня не было вообще никакого.
Меня спрашивали «как так? почему у тебя исходников не осталось?», я-то знаю, что если понадобится — смогу написать лучше :) Ответ — да, стыдно, по возможности стараюсь переделывать :)
Когда мне становится стыдно — я его переписываю.
Бывает откроешь свой код спустя года 3, берешься за голову и думаешь: «В рот мне ноги, это не я!»
Написанный мною код, не вызывает у меня не стыда, не гордости, не радости. Просто так его не переписываю, только если нашел дыру в безопасности или способ оптимизировать его в разы.
Может я какой-то не правильный, но мне всегда охота переписать код которому есть пару месяцев.
Раньше было очень стыдно, потом привык.:) Впрочем, весь актуальный код я время от времени рефакторю. Иногда удивляюсь, как я мог такое написать, но почти без эмоций.
Тут еще вопрос стыдно перед кем. Вот не знаю, может у меня такая самокритика высокая, но когда я поднимаю какой-нибудь древний проект с написанным мной индусским кодом, мне стыдно прежде всего перед собой. А вот когда кто-то критикует мой код, я просто воспринимаю это как желание мне помочь и внимаю этой критике, но чувства стыда нет.
Стыдно, потому что себе же хуже сделал. Не нарочно, конечно. Но тем не менее. И переписать хочется. Но сроки, обычно, поджимают :(
Стыдно — это эмоции.
Если кривость код локальная, сам он работает и при этом не создает проблем для развития проекта, то поддаваться эмоциям и начинать его тыкать палочкой, попутно внося новые баги — достаточно нерациональное занятие.
Если кривость нелокальная и код создает проблемы, то приходится рефакторить, точно так же, как если бы он был не крив, а просто неактуален.
Более того, когда кривость очевидна даже на этапе написания — это не всегда повод выбрать более джедайский путь с внеплановым рефакторингом.
Написал херово, поставил FIXME:, когда таких кусков в одном месте накопилось достаточно, сложился опыт и практические требования, и уже можно посмотреть на проблему более широко — вот тогда уже делать правильно.
Совершенно не понимаю, зачем тут чего-то стыдиться.
Если кривость код локальная, сам он работает и при этом не создает проблем для развития проекта, то поддаваться эмоциям и начинать его тыкать палочкой, попутно внося новые баги — достаточно нерациональное занятие.
Если кривость нелокальная и код создает проблемы, то приходится рефакторить, точно так же, как если бы он был не крив, а просто неактуален.
Более того, когда кривость очевидна даже на этапе написания — это не всегда повод выбрать более джедайский путь с внеплановым рефакторингом.
Написал херово, поставил FIXME:, когда таких кусков в одном месте накопилось достаточно, сложился опыт и практические требования, и уже можно посмотреть на проблему более широко — вот тогда уже делать правильно.
Совершенно не понимаю, зачем тут чего-то стыдиться.
Поддерживаю. У меня было две основные ситуации:
1. Код писался в относительно далеком прошлом — да, конечно, смотреть сейчас жутковато. Но писал я его на своем тогдашнем уровне — не написал бы так, не научился бы. Так что стыда не испытываю — просто констатирую факт — тогда писал плохо, сейчас пишу лучше.
2. Код пишется сейчас, но в спешке — т.е. иногда неоптимально, невылизанно. Это является конкретным решением для конкретного проекта с учетом сроков, планов по доработке и так далее. Почему должно быть стыдно — тоже непонятно. Иногда по коду планируется рефакторинг.
1. Код писался в относительно далеком прошлом — да, конечно, смотреть сейчас жутковато. Но писал я его на своем тогдашнем уровне — не написал бы так, не научился бы. Так что стыда не испытываю — просто констатирую факт — тогда писал плохо, сейчас пишу лучше.
2. Код пишется сейчас, но в спешке — т.е. иногда неоптимально, невылизанно. Это является конкретным решением для конкретного проекта с учетом сроков, планов по доработке и так далее. Почему должно быть стыдно — тоже непонятно. Иногда по коду планируется рефакторинг.
я вот что скажу — если у вас хватило смелости самому себе признать, что код плохой, то надо гордиться а не стыдиться, ведь вы выросли как программист за время, прошедшее с написания.
Я все понимаю, но почему без вопросительного знака?
Просто ни за что не соглашусь, что мой код плох. :)
(Минусаторам: это я не о себе.)
(Минусаторам: это я не о себе.)
Нашел код, за который стыдно? Перепиши, если можешь сделать лучше.
Если вам не хочется переписать код, значит, вы в тупике эволюции! Поверните назад или поменяйте свой путь.
>'Поверните назад'
Тоесть переписать свой код? Я наверно от вашего утверждения впаду в рекурсию.
Тоесть переписать свой код? Я наверно от вашего утверждения впаду в рекурсию.
Ближе к жизни. Тут ключевое слово тупик. Когда заходишь в тупик есть 2 выхода: лезть на многометровую стену — это худший вариант, ибо умный в гору не пойдет (с). Лучший — повернуть назад (посмотреть что вы упустили, мб какой поворот проглядели). Ну и, конечно, можно убиться об стену.
Стремление переписать код — это стремление сделать лучше, стремление к развитию. Если вы не хотите переписать код и у вас есть время — вы не развиваетесь. Вам стоит больше уделить вниманию вашей области.
Стремление переделать/улучшить есть у любого человека будь он программистом, дизайнером, писателем.
Есть ещё момент. Если вам нравится ваш код 1-2 годичной давности, то вы тоже в тупике эволюции.
Стремление переписать код — это стремление сделать лучше, стремление к развитию. Если вы не хотите переписать код и у вас есть время — вы не развиваетесь. Вам стоит больше уделить вниманию вашей области.
Стремление переделать/улучшить есть у любого человека будь он программистом, дизайнером, писателем.
Есть ещё момент. Если вам нравится ваш код 1-2 годичной давности, то вы тоже в тупике эволюции.
Я в своем коменте изображал ход мыслей программиста ответившего на 4й вариант тоесть он не считает что его код плох, тоесть вы этому персонажу советуете повернуться назад что он не хочет делать в итоге от раздумий он впадает в парную рекурсию функций которые проверяют последный раз результаты друг друга, тоесть этот программист если он искрене ответил на 4й вариант какраз в тупике так как он не знает что делать, в глубине процессора (души) он понимает что ему нужно совершенствоваться но ему лень и он оправдывается тем что он лучше некоторых других и может писать некоторые тупые вещи.
Ну развели тут квази-философию и какой-то детский абсолютизм. Кривой код писать МОЖНО, если это просто и быстро и ключевой момент — ЛОКАЛЬНО. Т.е. если в этом кривом коде будет какая-то проблема, то его изменение никак не затронет все остальное. В общем, если снаружи метода не понятно, что этот метод — забыдлокоден, то все нормально. Главное иметь абстракцию хорошую. Вот если сделать что-то хреново, а потом начать это юзать везде-везде, то потом потребуется огромное количество усилий, что бы это исправить. А если это будет какой-нибудь метод-объектик, который хорошо абстрагирован, но пусть внутри какой-нибудь быдлокод, то это не плохо. Совсем не плохо.
А по мне так вообще опрос странный. Стыдно — не стыдно. Программирование не то место, где д.б. стыдно или не стыдно за свой код — есть хороший код, а есть плохой и иногда лучше написать достаточно кривой и не очень красивый код, вместо траты кучи времени на мифическую красоту. В конце концов этот быдлокод можно откомментировать хорошо и все все поймут, пусть даже коммент будет больше кода.
А по мне так вообще опрос странный. Стыдно — не стыдно. Программирование не то место, где д.б. стыдно или не стыдно за свой код — есть хороший код, а есть плохой и иногда лучше написать достаточно кривой и не очень красивый код, вместо траты кучи времени на мифическую красоту. В конце концов этот быдлокод можно откомментировать хорошо и все все поймут, пусть даже коммент будет больше кода.
Толи я живу в каком-то другом мире, толи лыжи не натер… Заказчики вроди такие же как и везде: «сделай это, это и это да побыстрей и подешевле», НО никто из круга моих знакомых не говорил: «мне за это не платят», а всегда пишут максимально качественный код, который возможен в конкретных условиях. И всем стыдно за каждый, даже самый маленький костыль. Увы, мы живем в несовершенном мире (но это смотря как посмотреть)) и условия не всегдя бывают благоприятными, но по крайней мере пытаться хорошо делать то, чем занимаешься — это достойно профессионала. На эту тему есть очень хорошая книга: «Дзэн и искусство ухода за мотоциклом», рекомендую.
з.ы. сорри за сумбур, потоки мыслей кофликтуют за ресурс мозга)
з.ы. сорри за сумбур, потоки мыслей кофликтуют за ресурс мозга)
>а всегда пишут максимально качественный код, который возможен в конкретных условиях
Бюджет проекта, скажем, ваш месячный доход, сдать нужно (дедлайн) через два месяца. Есть вариант сделать за месяц «набор костылей», а дальше заниматься другим проектом или просто отдыхать, а есть за два месяца сделать нормальный проект, но получить оплату только за месяц работы. Функциональность не изменится ни на йоту. Выбор однозначен?
Бюджет проекта, скажем, ваш месячный доход, сдать нужно (дедлайн) через два месяца. Есть вариант сделать за месяц «набор костылей», а дальше заниматься другим проектом или просто отдыхать, а есть за два месяца сделать нормальный проект, но получить оплату только за месяц работы. Функциональность не изменится ни на йоту. Выбор однозначен?
>Выбор однозначен?
За интернет во втором месяце платит мама.
За интернет во втором месяце платит мама.
Вообще не всегда. Если проект интересный и подразумевает возможность красиво решить сложную задачу — я бы решил сделать это красиво.
Почему? В первом случае я получаю N денег и теряю месяц впустую, зато имею свободный месяц. Во втором случае я получаю N денег и опыт реализации интересного проекта, который потом уж точно не будет лишним.
Почему? В первом случае я получаю N денег и теряю месяц впустую, зато имею свободный месяц. Во втором случае я получаю N денег и опыт реализации интересного проекта, который потом уж точно не будет лишним.
Простите не понял «сдать нужно (дедлайн) через два месяца», почему если проект рассчитан на два месяца и за это время сделать его нормально то «получить оплату только за месяц работы.»?
Проект нужно сдать через два месяца (запуск привязан к конкретной дате), сделать можно за месяц костылями (например есть уже какая-то основа), а можно за два красиво (например основу переписать).
Видимо имеется ввиду что или получаете за месяц стандартную месячную зарплату, или за два месяца по половинке месячной.
Угу, в общем от того сколько его реально будете делать бюджет не зависит.
Боже, я один дурак не понимаю? Почему в проекте на два месяца заложена зарплата на один месяц? Это вообще как? Или это к тому, что можно за месяц сделать и получить изначально рассчитаные на два месяца деньги?
Проект — на месяц. Но можно затянуть на два месяца.
Ай все, я отказываюсь спорить с человеком, который противоречит сам себе. Прочитайте пожалуйста свои комментарии по порядку.
Это мой первый коммент в ветке. Сначала вам писал VolCh, потом — VenomBlood, после этого — я. У вас заказчик заказывает проект, предлагает зарплату за месяц, но результат может подождать два месяца. Ситуация реальная и очевидная. Не понимаю, что тут трудного.
Не, не один. Я тоже не понимаю, что за планирование такое. На мой взгляд, планирование сроков должно быть таким, что бы на выходе получать нормальный поддерживаемый код, а не костыль-коллекшн. Судя по всему, для этого проекта это 2 месяца и оплата должна быть соответствующая, т.е. обсуждаемый проект стоит два человеко-месяца, так что решать тут заказчику, получить проект на один раз за половину стоимости или нормальный, но за полную.
А то, что любой проект можно сделать быстрее, но менее качественно, это очевидно.
А то, что любой проект можно сделать быстрее, но менее качественно, это очевидно.
Мне в такие моменты хочется достать с полочки запылившуюся машину времени, вернуться во время написания кода и хорошенько заехать себе по шее.
Ну как бы стыдно, конечно, но это неизбежно, если программист растет. Часто даже код месячной давности уже не радует. Но не переписывать же рабочие проекты.
Мне стыдно за то что я писал до сегодняшнего дня, и так каждый день. (с) Как то так оно звучало, мне понравилось.
Наверное большое счастье быть таким человеком, чтобы каждый день делать шаг вперед.
Подскажите, как 100% определить что мой код — говно?
Существуют, т. н. bad smells. Посмотрите в «Рефакторинге» у Фаулера.
А есть где-нибудь список этих душков, буквально по предложению на каждый?
Есть.
Я не программист. Умею только найти чужой код/функции и подогнать их под себя. И я понятия не имею он плохой или хороший. Но когда это все работает, мне ни капельки не стыдно, я этим горжусь)
Я дизайнер! Но решил, что мне нужен js и python на хорошем уровне.
Сегодня написал первый код который мне нравится, посмотрите?
Сегодня написал первый код который мне нравится, посмотрите?
Вроде нормально.
Мутулз используете не зря. Вместо
имхо, не очень удачное решение, глаз спотыкается. лучше перенесите на следующую строчку.
Будет валить скрипты в некоторых браузерах без заглушки.
В данном конкретном случае лучше заменить на
Потому что уменьшится вложенность
Выглядят как константы, хотя вы их измененяете во время исполнения приложения:
Логичнее использовать
Можно пойти дальше и сразу присваивать имя метода
По поводу объекта
Но на самом деле это мелкие придирки, а код — очень хорош. Как я уже сказал — MooTools используете не зря, очень хороший фреймворк.
new Array() лучше использовать []. Через new Array(length) пишите только тогда, когда необходимо явно указать длину массива. Это бывает крайне редко ;) Зачем в _initHtml использовать clazz вместо this кое-где? Или используйте везде (для того, чтобы сократить объем сжатого кода) или не используйте вообще) name: function () { var clazz = this;
имхо, не очень удачное решение, глаз спотыкается. лучше перенесите на следующую строчку.
console.log(clazz.ALL_TAGS);
Будет валить скрипты в некоторых браузерах без заглушки.
_setTags: function (tags) {
var all_tags = this.ALL_TAGS;
tags.each(function (t) {
if (t) {
// code
}
})
_setTags: function (tags) {
var all_tags = this.ALL_TAGS;
tags.each(function (t) {
if (t) {
// code
}
})
В данном конкретном случае лучше заменить на
_setTags: function (tags) {
var all_tags = this.ALL_TAGS;
tags.each(function (t) {
if (!t) return;
// code
})
Потому что уменьшится вложенность
clazz.CHECKBOXES.append([{"tag": tag[0], "checkbox": checkbox}]);
clazz.FIELD_SET.adopt(wrap);
Выглядят как константы, хотя вы их измененяете во время исполнения приложения:
ROWS: new Array(),
CHECKBOXES: new Array(),
ALL_TAGS: new Array(),
RECORDS: new Array(),
RECUIRED_TAGS: new Array(),
RECUIRED_TAGS — правильно писать REQUIRED_TAGS.var missing = false;
clazz.RECUIRED_TAGS.each( function(t, i) {
if (r.tags.indexOf(t) === -1) {
missing = true;
}
});
if (missing) {
$(r.tr).addClass("hidden");
} else {
$(r.tr).removeClass("hidden");
}
Логичнее использовать
some и contains:var missing = this.requiredTags.some(function () {
return !r.tags.contains(t);
})
if (missing) {
$(r.tr).addClass("hidden");
} else {
$(r.tr).removeClass("hidden");
}
Можно пойти дальше и сразу присваивать имя метода
var methodName = this.requiredTags.some(function () {
return !r.tags.contains(t);
}) ? 'addClass' : 'removeClass';
$(r.tr)[methodName]("hidden");
По поводу объекта
options — более в стиле JavaScript использовать camelCaseНо на самом деле это мелкие придирки, а код — очень хорош. Как я уже сказал — MooTools используете не зря, очень хороший фреймворк.
Ого! Спасибо!
Проблема с капсом (константами) стоит решить через _required_tags? (сейчас в голову пришло)
очень понравилось вот это:
не знал про вызов метода через []
Проблема с капсом (константами) стоит решить через _required_tags? (сейчас в голову пришло)
очень понравилось вот это:
var methodName = this.requiredTags.some(function () {
return !r.tags.contains(t);
}) ? 'addClass' : 'removeClass';
$(r.tr)[methodName]("hidden");
не знал про вызов метода через []
Ну смотрите. Если это приват/протектет переменная, то стоит начать с подчеркивания.
ПИСАТЬ_КАПСОМ стоит только константы.
Использовать under_score в JavaScript вообще не стоит.
Потому, есть два варианта:
Кстати, не знаю почему, но в документации я этого не видел. Нашел в исходниках. Вы можете делать protected методы в Мутулз:
Их можно будет вызывать только из класса и его наследников.
Кстати, почему
Еще мне не очень нравится этот кусок:
Думаю, изящнее было бы переписать так:
Тем более, таким образом значительно сократится метод
ПИСАТЬ_КАПСОМ стоит только константы.
Использовать under_score в JavaScript вообще не стоит.
Потому, есть два варианта:
// если свойства публичные
rows: [],
checkboxes: [],
allTags: [],
records: [],
requiredTags: [],
// если свойства приватные
_rows: [],
_checkboxes: [],
_allTags: [],
_records: [],
_requiredTags: [],
Кстати, не знаю почему, но в документации я этого не видел. Нашел в исходниках. Вы можете делать protected методы в Мутулз:
getRows: function () {
this.rows = this.element.getChildren("tbody tr");
}.protect(),
getCells: function (row, column) {
return row.getChildren("td:nth-child("+column+")");
}.protect(),
Их можно будет вызывать только из класса и его наследников.
Кстати, почему
getRows на самом деле ничего не возвращает, как подобает настоящему геттеру, а устанавливает this.rows?Еще мне не очень нравится этот кусок:
options: {
// ..
wrapper_id: 'tbl_wrapper',
wrapper_class: 'tbl_c_wrapper',
form_id: 'tbl_form',
form_class: 'tbl_c_form',
fieldset_id: 'tbl_fieldset',
fieldset_class: 'tbl_c_fieldset',
legend_id: 'tbl_legend',
legend_class: 'tbl_c_legend',
checkbox_id: 'tbl_checkbox',
checkbox_class: 'tbl_c_checkbox',
chk_wrapper_id: 'tbl_chk_wrapper',
chk_wrapper_class: 'tbl_c_chk_wrapper'
}
Думаю, изящнее было бы переписать так:
options: {
// ..
wrapper : { 'id' : 'tbl_wrapper' , 'class' : 'tbl_c_wrapper' },
form : { 'id' : 'tbl_form' , 'class' : 'tbl_c_form' },
fieldset : { 'id' : 'tbl_fieldset' , 'class' : 'tbl_c_fieldset' },
legend : { 'id' : 'tbl_legend' , 'class' : 'tbl_c_legend' },
checkbox : { 'id' : 'tbl_checkbox' , 'class' : 'tbl_c_checkbox' },
chkWrapper : { 'id' : 'tbl_chk_wrapper', 'class' : 'tbl_c_chk_wrapper' }
}
Тем более, таким образом значительно сократится метод
_initHtmlinitHtml: function () {
this.wrapper = new Element('div' , this.options.wrapper);
this.form = new Element('form', this.options.form)
.set({
action: '',
events: {
'submit': function (e) { new Event(e).stop(); }
}
});
this.fieldSet = new Element('fieldset', this.options.fieldset)
.adopt(new Element('legend', clazz.options.legend).set({
'text': clazz.options.title,
}));
this.wrapper.adopt(this.form.adopt(this.fieldSet));
// this.options.container || document.body - не нужно, у нас и так по-умолчанию document.body
$(this.options.container).adopt(this.wrapper);
}.protect(),
А как же вариант: «не стыдно, но некоторый мой прошлый код — говно, я рассматриваю это как мой рост как программиста».
Мне иногда стыдно за чужой код.
Ну стыдно или не стыдно это уже в прошлом, а в настоящем?
Вы пишете идеальный код?
— нет, но что-то постоянно тянет переписать, я готов бы его бесплатно исправлять, дали бы время;
— нет, но мне немного не по себе, мурашки..., а вдруг кто заглянет?
— нет и мне посрать, сказали сделать быстро — я сделал. я получил деньги, а код работает;
— иногда, когда припрут;
— иногда, когда есть настроение и никто не мешает;
— всегда, и никто и ничто не заставит меня написать плохой код.
Вы пишете идеальный код?
— нет, но что-то постоянно тянет переписать, я готов бы его бесплатно исправлять, дали бы время;
— нет, но мне немного не по себе, мурашки..., а вдруг кто заглянет?
— нет и мне посрать, сказали сделать быстро — я сделал. я получил деньги, а код работает;
— иногда, когда припрут;
— иногда, когда есть настроение и никто не мешает;
— всегда, и никто и ничто не заставит меня написать плохой код.
Я не программист, но мне стыдно, что мои скрипты зачастую написаны криво.
Все врут.
govnokod.ru по колено в коде.
Кто не знает как выглядит плохой код, может ознакомиться с его примерами. =)
Кто не знает как выглядит плохой код, может ознакомиться с его примерами. =)
А где же пункт «я знаю наизусть названия всех функций PHP»? :)
А Вам не стыдно, что вы в детстве ходили под себя? :)
Развитие — это правильно.
Развитие — это правильно.
Именно это и хотел написать.
Если когда-то давно писали плохой код, то это одно. Человек постоянно совершенствуется и вполне логично, что прошлогодний код будет плохим. Но стоит ли из-за этого переживать и портить себе настроение?
С другой стороны, можно здесь и сейчас писать плохой код, зная что он плохой. Но я такую ситуацию могу представить разве что при горящих сроках.
Если когда-то давно писали плохой код, то это одно. Человек постоянно совершенствуется и вполне логично, что прошлогодний код будет плохим. Но стоит ли из-за этого переживать и портить себе настроение?
С другой стороны, можно здесь и сейчас писать плохой код, зная что он плохой. Но я такую ситуацию могу представить разве что при горящих сроках.
А разве хороший код пишется дольше плохого? Особенно при горящих сроках. Или как всегда: «Нет времени сделать нормально, но есть время сделать дважды»?
Это ни в коем случае не претензия, и тем паче не к вам лично.
Просто при горящих сроках, по моему частному мнения, имеет смысл делать все сразу аккуратно, а лучше черезмерно аккуратно, дабы не поджигать сроки еще больше необходимостью переделок.
Это ни в коем случае не претензия, и тем паче не к вам лично.
Просто при горящих сроках, по моему частному мнения, имеет смысл делать все сразу аккуратно, а лучше черезмерно аккуратно, дабы не поджигать сроки еще больше необходимостью переделок.
ИМХО. Плохой код можно сразу начать писать и он будет нормально работать в текущих условиях.
А чтоб сделать нормальную, развиваемую структуру, которая учтет все нюансы, понадобится время на подумать.
Блин, да самый простой пример — «костыли» и хотфиксы. Чтоб сейчас заработало как можно скорее, а дальше разберемся… если время будет.
А чтоб сделать нормальную, развиваемую структуру, которая учтет все нюансы, понадобится время на подумать.
Блин, да самый простой пример — «костыли» и хотфиксы. Чтоб сейчас заработало как можно скорее, а дальше разберемся… если время будет.
В этом и дело, если вам стыдно за ранее написанный код, значит вы выросли, развиваетесь.
Тут есть разница очевидная разница: в детстве я пИсался неосознанно, а плохой код как правило писАлся осознано :)
если надо сделать быстро, можно и плохо сначала написать, а потом поправить
Есть стратегия по которой новый модуль пишется что бы работал, выстраивать архитектуру для каждого модуля программного продукта, весьма затратно.
Когда система развивается и появляется связь старого модуля с разрабатываемого, тогда полностью переписывается и старый код. Но в любом случае время потраченное на плохой код уже не вернуть.
Когда система развивается и появляется связь старого модуля с разрабатываемого, тогда полностью переписывается и старый код. Но в любом случае время потраченное на плохой код уже не вернуть.
Я плохой код писал, пишу и буду писать ) так как есть люди которые писали пишут и будут писать лучше меня)
Плохой код обычно — побочный продукт обучения. Чем больше кода пишет человек, тем скорее код станет хорошим. Не надо его стыдиться.
Не надо демократию разводить — я уже насмотрелся на код бесстрашных программистов. Благими намерениями вымощена дорога в ад.
ну да, однако собственный старый код иногда хочется переписать, если он все еще доступен :)
Рез-тат опроса вызывает у меня жуткий хохот, учитывая, что я постоянно на вопрос «как бы вы это переписали?» получаю ответ «та забей, напиши коммент о том, что это за говно и иди дальше».
А где пункт: बुरा कोड क्या है?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вам стыдно за плохой код написанный вами