Низкое качество stories

[adda_]

кстати, а, что не так с "button"? Как должно быть? btnCancel? pipkaCancel?

На самом деле скажем было бы неплохо знать что эта кнопка отменяет. Например btnCancelInvoice или что то в этом роде. Опять таки, если пишем апликуху где больше пары кнопок, то использовать цвета на прямую - признак того что человек не думает дальше сегодняшнего дня. Цвета надо переопределить и вместо Blue скажем исползовать colorCancel или colorActive или что то в этом роде. Лично я рефакторю имена процедур, переменных и так далее несколько раз добиваясь ясности и хорошей читабельности кода.

[adda_]

у кого-то понедельник круто начался

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

[stenking]

На самом деле скажем было бы неплохо знать что эта кнопка отменяет. Например btnCancelInvoice или что то в этом роде..

А если код такой

Code: Select all

function cancelInvoice()
{
 Button button = new Button("Cancel");
}

Ну и вообще понятно же с контента что это просто абстрактный пример.

[АццкоМото]

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

это классический пример, когда человек на седьмом десятке все еще не умеет читать, а апломб - как у 17-летнего. написано же русским языком: "утрированный пример". не доходит? перечитайте

За использование имени "button" я бы увольнял без выходного пособия без разговоров. Читайте книжки молодые люди. Хотя конечно вам не до того, вы изучаете новые фреймворки.

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

Ну ты и урод бля.. А помню писал мне что то в личку. Такого говнюка как ты на этом форуме искать и искать..

Что, больно сырым тапком по лицу получить? Не надо было нарваться. Старикам у нас почет только пока они не выпендриваются, ага

[adda_]

_____

[АццкоМото]

модератор: переход на личность. Предупреждение

модератор: публичное обсуждение действий модератора. Бан 2 недели
Извольте изучить, что такое переход на личность, и более не позориться.

[АццкоМото]

Аццкий мопед, ты у меня в списке "не-друзей". Не вижу я твоих комментов, "дурилка картонная". Таких хамов, как ты, надо гнать с привета ссаными тряпками.

Мне глубоко насрать на тебя и твои списки.

[Easbayguy]

Он улетел, но к сожалению обещал вернуться!

[Easbayguy]

А если код такой

Code: Select all

function cancelInvoice()
{
 Button button = new Button("Cancel");
}

Отвечу по казахски : оте жақсы

мен жаман мен жаксы

[adda_]

На самом деле скажем было бы неплохо знать что эта кнопка отменяет. Например btnCancelInvoice или что то в этом роде..

А если код такой

Code: Select all

function cancelInvoice()
{
 Button button = new Button("Cancel");
}

Ну и вообще понятно же с контента что это просто абстрактный пример.

Это плохой код. Извините. Вот хороший

Code: Select all

function createCancelInvoiceButton()
{
 Button cancelInvoiceButton = new Button("Cancel");
}

Почему этот код хороший, а ваш плохой, подумайте сами.

[caltrain]

Code: Select all

function createCancelInvoiceButton()
{
 Button cancelInvoiceButton = new Button("Cancel");
}

Почему этот код хороший, а ваш плохой, подумайте сами.

если в такой контекст добавить ещё одну кнопочку, то конечно button - выглядит уныло (особенно если их две)
Есть ещё какие-то преимущества?

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

Ещё, если использовать хороший IDE, то рефакторинг cancelInvoiceButton - button происходит быстро. Вы то чай, не vi редактируете

[Prosche]

На самом деле скажем было бы неплохо знать что эта кнопка отменяет. Например btnCancelInvoice или что то в этом роде..

А если код такой

Code: Select all

function cancelInvoice()
{
 Button button = new Button("Cancel");
}

Ну и вообще понятно же с контента что это просто абстрактный пример.

Это плохой код. Извините. Вот хороший

Code: Select all

function createCancelInvoiceButton()
{
 Button cancelInvoiceButton = new Button("Cancel");
}

Почему этот код хороший, а ваш плохой, подумайте сами.

На самом деле и у вас и у Мото плохие примеры. Аццкий не знает, что такое самодокументированный код, его пример обычного кода с плохой документацией, а само... это когда имена классов, переменных и функций четко говорят о своем назначении и не допускают неопределенностей.
И тут казалось бы ваш пример выиграл, но ваш код, adda_, тоже плох, вы даже сами объяснили почему выше, он требует бесконечного рефакторинга. Ничего страшно в button нет, камман сенс подсказывает, что если у нас в cancelInvoice определена кнопка, одна, она и отвечает за этот кансел. Писать километровые имена для этого совсем не обязательный. А еще вы своим примером сломали архитектуру. Ограничили функцию, которая ответственна за отмену инвойса только созданием кнопки, а если завтра она еще таймер будет создавать, который автоматом канселит инвойс? вы что будете делать, переименовывать ее в createCancelInvoiceButtonAndTimer? Я понимаю почему вам приходится рефакторить 100500 раз все.
Пример стенкина хороший вощем, а ваш плохой.

[adda_]

И тут казалось бы ваш пример выиграл, но ваш код, adda_, тоже плох, вы даже сами объяснили почему выше, он требует бесконечного рефакторинга. Ничего страшно в button нет, камман сенс подсказывает, что если у нас в cancelInvoice определена кнопка, одна, она и отвечает за этот кансел. Писать километровые имена для этого совсем не обязательный. А еще вы своим примером сломали архитектуру. Ограничили функцию, которая ответственна за отмену инвойса только созданием кнопки, а если завтра она еще таймер будет создавать, который автоматом канселит инвойс? вы что будете делать, переименовывать ее в createCancelInvoiceButtonAndTimer? Я понимаю почему вам приходится рефакторить 100500 раз все.
Пример стенкина хороший вощем, а ваш плохой.

Я с вами не согласен.
Во первых предполагается что это реальная система где множество элементов управления, а не один - два.
Во вторых в данном примере функция Создает кнопку и более ничего. Функция не канселит инвойс, канселить будет обработчик события который повешен на кнопке.
Третье - вы к сожалению не знакомы с одним из главных принципов написания хорошего кода - функция должна выполнять одну и только одну задачу, но делать это хорошо.
В реальной жизни функция не только созлала бы кнопку но и установила ее свойства, размер, цвет надписи, положение, подключила бы обработчики событий. Т.е. там было бы с десяток строчек кода. Добавлять туда что то совершенно излишне.
Если нам надо создавать таймер, то будет другая функция которая это сделает.
А все эти функции будут вызываться скажем из другой функции.

Code: Select all

  function createInvoiceControls ()
  {
      createInvoceCancelButton ();
      createInvoceSubmitButton ();
      ....
      createInvoceAutoProcessTimer();
      ...
      
  }

.
Обратите внимание, что когда я написал последний пример, то оказалось что для лучшей читаемости кода имеет смысл поменять название функции - с createCancelInvoceButton на createInvoiceCancelButton. Т.е перерефакторить код. Что занимает на самом деле меньше минуты. Но оно того стоит.
Если бы я писал этот код, то возможно через какое то время я бы еще его порефакторил, потому что имя функции createInvoceControls не совсем правильно отображает то что функция делает. А именно создает не только элементы управления но и таймеры, которые не явлеются контролами. Скорее всего я бы убрал оттуда создание таймера, и вынес его туда где мы будем создавать какую то логику реализованную на таймерах. Т.е. три - четыре цикла рефакторинга я бы сделал обязательно.

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

[M. Ridcully]

Люди, спасибо вам - почитал ваши жаркие споры о том, как назвать кнопку и понял, что у меня совсем даже неплохая работа!

[adda_]

Люди, спасибо вам - почитал ваши жаркие споры о том, как назвать кнопку и понял, что у меня совсем даже неплохая работа!

Это не о кнопке, скажем я практически не пишу интерфейсы сейчас. Это о том как надо писать код, который легко поддерживается и модифицируется. В отличии от так называемого "говнокода" в котором автор через месяц после его написания не может разобраться и модифицировать.
Кстати почему то значительная часть публики связывает понятие "говнокод" с языком на котором он написан. Т.е. предполагается что использование суперпупер модных технологий автоматически позволяет писать супер код. Судя по тому что я здесь прочитал, это не так.

[M. Ridcully]

Люди, спасибо вам - почитал ваши жаркие споры о том, как назвать кнопку и понял, что у меня совсем даже неплохая работа!

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

Вы требуете невозможного

[adda_]

Вы требуете невозможного

Вы не правы. Я от вас ничего не требую. Но могу сказать, что я сейчас пишу именно такой код и пытаюсь добиться чтобы в моей группе писали такой код.

[nyekimov]

На самом деле и у вас и у Мото плохие примеры. Аццкий не знает, что такое самодокументированный код, его пример обычного кода с плохой документацией, а само... это когда имена классов, переменных и функций четко говорят о своем назначении и не допускают неопределенностей.
И тут казалось бы ваш пример выиграл, но ваш код, adda_, тоже плох, вы даже сами объяснили почему выше, он требует бесконечного рефакторинга. Ничего страшно в button нет, камман сенс подсказывает, что если у нас в cancelInvoice определена кнопка, одна, она и отвечает за этот кансел. Писать километровые имена для этого совсем не обязательный. А еще вы своим примером сломали архитектуру. Ограничили функцию, которая ответственна за отмену инвойса только созданием кнопки, а если завтра она еще таймер будет создавать, который автоматом канселит инвойс? вы что будете делать, переименовывать ее в createCancelInvoiceButtonAndTimer? Я понимаю почему вам приходится рефакторить 100500 раз все.
Пример стенкина хороший вощем, а ваш плохой.

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

Самодокументрованный код должен быть по умолчанию, писать его должны уметь, но именно потому что далеко не все умеют писать, далеко не все "надо быстро поправить фичу" будут фиксить и самодокументированный код, поэтому документация нужна, именно не с детальной имплементацией, а в общих чертах - а-ля frd. И мы кажется о разных вещах говорим, есть а-ля frd, а есть API. Вот API в каких то случаях пренебречь можно, но если б самодокументированный код был панацеей, то зачем API пишут гуглы и прочие на более менее серьезном проекте? Только лишь чтобы паблик публика могла читать?

Я честно видел такие тикеты от горе тестеров - там то не работает. Там это где именно? Какая версия клиента? Как должно работать?
Но по мне это все как раз таки и идет от культуры компании, где то тимлиды стоят за своих и заставляют тестеров/менеджеров писать качественно тикеты. Где то считают, что девелопер должен успевать все и уметь спрашивать все устно, так как это типо быстрее всего.
Одна фирма прям ролик для открытых вакансий сняла как у них все сидят за одним сплошным столом и друг другу в монитор смотрят, мол если что-то надо то они все устно спрашивают. Представляете какой гул там стоит? И как можно сконцентироваться над своей фичей и писать код без багла. Меня от одного ролика стошнило )
Паралельно проводят исследования или просто пишут статьи, что если разработчика отвлечь от кода, то он потом минимум часа пол будет погружаться назад)

[Мальчик-Одуванчик]

кстати, а, что не так с "button"? Как должно быть? btnCancel? pipkaCancel?

На самом деле скажем было бы неплохо знать что эта кнопка отменяет. Например btnCancelInvoice или что то в этом роде. Опять таки, если пишем апликуху где больше пары кнопок, то использовать цвета на прямую - признак того что человек не думает дальше сегодняшнего дня. Цвета надо переопределить и вместо Blue скажем исползовать colorCancel или colorActive или что то в этом роде.

А если эта кнопка в зависимости от контекста выполняет ту или иную роль? Как её тогда называть?
как раз книжки и пишут (старый добрый Гради Буч) что называть её следует именно button.

[Мальчик-Одуванчик]

Вообще я бы не стал смешивать сущность "инвойс" и его представление.
То есть обошелся бы без термина invoice button или cancel button - они тут вообще не впёрлись.
Представление инвойса на экране десктопа или веб-формы вполне может генериться фабрикой классов опосредованно от прямого кодирования.

[adda_]

кстати, а, что не так с "button"? Как должно быть? btnCancel? pipkaCancel?

На самом деле скажем было бы неплохо знать что эта кнопка отменяет. Например btnCancelInvoice или что то в этом роде. Опять таки, если пишем апликуху где больше пары кнопок, то использовать цвета на прямую - признак того что человек не думает дальше сегодняшнего дня. Цвета надо переопределить и вместо Blue скажем исползовать colorCancel или colorActive или что то в этом роде.

А если эта кнопка в зависимости от контекста выполняет ту или иную роль? Как её тогда называть?
как раз книжки и пишут (старый добрый Гради Буч) что называть её следует именно button.

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

[adda_]

Вообще я бы не стал смешивать сущность "инвойс" и его представление.
То есть обошелся бы без термина invoice button или cancel button - они тут вообще не впёрлись.
Представление инвойса на экране десктопа или веб-формы вполне может генериться фабрикой классов опосредованно от прямого кодирования.

Знаете ли, если мы отвяжем имена контролов на десктопе от функциональности то получим интересную вещь. Вам приходит тикет - не работает кнопка Cancel на экране Invoice Search. А экранов у вас несколько сотен. И на каждом десятки кнопок. И вы начинаете искать.. И это самый простой пример.
Если у вас что то генерируется фабрикой классов, то тогда вообще вам надо серьезно проработать дизайн и названия каждого элемента, чтобы потом можно было как то найти откуда уши растут.
И самое главное - пропадает такая хорошая вещь, о которая существует в чистом коде. Чистый код можно читать как книгу, не задумываясь о имплементации и понимая что делает код.

[Мальчик-Одуванчик]

Вообще я бы не стал смешивать сущность "инвойс" и его представление.
То есть обошелся бы без термина invoice button или cancel button - они тут вообще не впёрлись.
Представление инвойса на экране десктопа или веб-формы вполне может генериться фабрикой классов опосредованно от прямого кодирования.

Знаете ли, если мы отвяжем имена контролов на десктопе от функциональности то получим интересную вещь. Вам приходит тикет - не работает кнопка Cancel на экране Invoice Search. А экранов у вас несколько сотен. И на каждом десятки кнопок. И вы начинаете искать.. И это самый простой пример.
Если у вас что то генерируется фабрикой классов, то тогда вообще вам надо серьезно проработать дизайн и названия каждого элемента, чтобы потом можно было как то найти откуда уши растут.
И самое главное - пропадает такая хорошая вещь, о которая существует в чистом коде. Чистый код можно читать как книгу, не задумываясь о имплементации и понимая что делает код.

У того же инвойса может быть несколько представлений, где в процессе его жизненного цикла нажатие на кнопку Cancel влечет за собой различные действия. Поэтому жесткая привязка к форме лишь усугубит. Для облегчения тестирования как раз проще, вообще отвязать представление от сущности (эт ниче что я про MVC банальщину тут перетираю?) и программисту достаточно знать что было вызвано действие Cancel относительно инвойса, неважно из какой сотен форм и какая именно кнопка при этом была нажата.
Понятно что замечательное свойство "натягивания совы на глобус", то есть генерация подобных форм инвойса под конкретного заказчика ( с учетом особенностей его бизнес-логики) или ординарного пользователя (skin) гораздо проще осуществить именно таким способом.

[Prosche]

И тут казалось бы ваш пример выиграл, но ваш код, adda_, тоже плох, вы даже сами объяснили почему выше, он требует бесконечного рефакторинга. Ничего страшно в button нет, камман сенс подсказывает, что если у нас в cancelInvoice определена кнопка, одна, она и отвечает за этот кансел. Писать километровые имена для этого совсем не обязательный. А еще вы своим примером сломали архитектуру. Ограничили функцию, которая ответственна за отмену инвойса только созданием кнопки, а если завтра она еще таймер будет создавать, который автоматом канселит инвойс? вы что будете делать, переименовывать ее в createCancelInvoiceButtonAndTimer? Я понимаю почему вам приходится рефакторить 100500 раз все.
Пример стенкина хороший вощем, а ваш плохой.

Я с вами не согласен.
Во первых предполагается что это реальная система где множество элементов управления, а не один - два.
Во вторых в данном примере функция Создает кнопку и более ничего. Функция не канселит инвойс, канселить будет обработчик события который повешен на кнопке.
Третье - вы к сожалению не знакомы с одним из главных принципов написания хорошего кода - функция должна выполнять одну и только одну задачу, но делать это хорошо.
В реальной жизни функция не только созлала бы кнопку но и установила ее свойства, размер, цвет надписи, положение, подключила бы обработчики событий. Т.е. там было бы с десяток строчек кода. Добавлять туда что то совершенно излишне.
Если нам надо создавать таймер, то будет другая функция которая это сделает.
А все эти функции будут вызываться скажем из другой функции.

Code: Select all

  function createInvoiceControls ()
  {
      createInvoceCancelButton ();
      createInvoceSubmitButton ();
      ....
      createInvoceAutoProcessTimer();
      ...
      
  }

.
Обратите внимание, что когда я написал последний пример, то оказалось что для лучшей читаемости кода имеет смысл поменять название функции - с createCancelInvoceButton на createInvoiceCancelButton. Т.е перерефакторить код. Что занимает на самом деле меньше минуты. Но оно того стоит.
Если бы я писал этот код, то возможно через какое то время я бы еще его порефакторил, потому что имя функции createInvoceControls не совсем правильно отображает то что функция делает. А именно создает не только элементы управления но и таймеры, которые не явлеются контролами. Скорее всего я бы убрал оттуда создание таймера, и вынес его туда где мы будем создавать какую то логику реализованную на таймерах. Т.е. три - четыре цикла рефакторинга я бы сделал обязательно.

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

Господи Иисусе, вместо простой абстракции, вы нагородили совершенно кошмарного монолитного кода, перемешали в кучу бизнес логику с графическим представлением... Вы наверно С-шник? Долго писали на процедурных языках?

[adda_]

Господи Иисусе, вместо простой абстракции, вы нагородили совершенно кошмарного монолитного кода, перемешали в кучу бизнес логику с графическим представлением... Вы наверно С-шник? Долго писали на процедурных языках?

Кроме обращения к Богу всуе, вы на самом деле ничего не сказали.
Я все же рекомендую вам прочитать эту вот книгу - http://ricardogeek.com/docs/clean_code.pdf" onclick="window.open(this.href);return false;
Это совершенно бесплатно. Возможно после этого вы начнете понимать то о чем я говорю.