Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Философия программирования > Выразительные названия методов

Автор: MystDeim 12.3.2010, 10:31

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

Автор: DarkProg 16.4.2010, 11:16

НУ приведу из своей жизни как я обзываю классы, надеюсь ещё нужно  Вот скажем есть у нас Школа в школе есть предметы и преподы которые преподают этот предмет создадим Запись Код type PredmetsAndPrepodauzhiePrepods=record  PredmetName:string;  PrepodsFIO:array of strings; end; Вот как-то в таком духе, чтобы было отражение того чего хочешь, мне помогает и сильно, даже в момент когда месяц проект в глаза не видел потом возвращаюсь и вспоминаю что было же как-то вроде так и точно нахожу.

Автор: kemiisto 16.4.2010, 11:25

Цитата(MystDeim @  12.3.2010,  11:31 ) Может кто-нибудь видел подобные статьи или руководства? Сильно зависит от языка. Гуглить "<название_языка> style guide".

Автор: Sartorius 16.4.2010, 11:34

У Макконела в "Совершенном коде" эта проблема, кажется, обсуждалась. В любом случае must read

Автор: kemiisto 16.4.2010, 11:39

Цитата(Sartorius @  16.4.2010,  12:34 ) В любом случае must read Вот уж на ***, простите, такой read. Аффтара - на кол, книгу - сжечь.

Автор: RockClimber 16.4.2010, 12:17

М. б. венгерская нотация (не системная, а обычная) спасет отца русской демократии?

Автор: kemiisto 16.4.2010, 12:30

Цитата(RockClimber @  16.4.2010,  13:17 ) М. б. венгерская нотация (не системная, а обычная) спасет отца русской демократии? О нет! Всё что угодно, только не венгерская нотация.

Автор: bars80080 16.4.2010, 14:58

а что, фантазии не хватает? отослать должнику извещение о об отказе в кредите: ourCow.fuckyouSpilberg();

Автор: Oxy 18.4.2010, 14:55

Цитата(kemiisto @  16.4.2010,  11:39 ) Аффтара - на кол, книгу - сжечь. аргументы

Автор: kemiisto 18.4.2010, 15:28

Цитата(Oxy @  18.4.2010,  15:55 ) аргументы Начнём с того, что ты задашь этот вопрос Sartorius, чтобы не отклоняться от хронологии событий. Цитата(Sartorius @  16.4.2010,  12:34 ) В любом случае must read Эту фразу ты почему то пропустил. А к моему мнению аппелируешь. Теперь собвственно аргументы: Большая часть советов - выжимка практического опыта конкретного программиста. Это означает, что теоретической базы за советами никакой нет. Часть советов - полезна, часть - бесполезна, а часть - вредна и губительна. Как и у многих практикующих программистов - огромныей пробел в плане структурного программирования. Непонимание важности жёсткой дисциплины кодирования.  Большая часть советов относится к языкам из первой ###пятёрки на tiobe.com. Мейнстрим, так сказать. А сколько волка не корми... Эти языки не поощраяют нормальное проектирование и уж тем более кодирование. Вместо того, чтобы пытаться устранить ляпы создателей языков практическими советами какого-то словоблуда... Ну, вы поняли.  Для тех, кто в БМП - фразы типа must read - типичный троллинг. Ответная реакция, естественно, была в том же ключе. На кол никога сажать не надо, книги сжигать тоже.  Читайте хоть "Mein Kampf". Но вот must read'ы - держите при себе. Ей богу, у нас возраст не тот, что must read'ами "кидаться".   MystDeim, ты куда пропал? Поговори с нами!

Автор: qweqwe 18.4.2010, 22:35

Цитата(kemiisto @  16.4.2010,  11:39 ) Вот уж на ***, простите, такой read. Аффтара - на кол, книгу - сжечь.  солидарен Цитата(kemiisto @  18.4.2010,  15:28 ) Теперь собвственно аргументы: Большая часть советов - выжимка практического опыта конкретного программиста. Это означает, что теоретической базы за советами никакой нет. Часть советов - полезна, часть - бесполезна, а часть - вредна и губительна. Как и у многих практикующих программистов - огромныей пробел в плане структурного программирования. Непонимание важности жёсткой дисциплины кодирования.  Большая часть советов относится к языкам из первой ###пятёрки на tiobe.com. Мейнстрим, так сказать. А сколько волка не корми... Эти языки не поощраяют нормальное проектирование и уж тем более кодирование. Вместо того, чтобы пытаться устранить ляпы создателей языков практическими советами какого-то словоблуда... Ну, вы поняли. добавлю свои пять копеек - многие советы Макконела, подходят для больших корпоративных проектов(БКП). БКП, это когда вы пишете код в течении (полу)года, потом вы его тестируете, итд. Соответственно, если вы работаете не так(если у вас множество коротких итераций), его советы будут не актуальны и даже вредны.

Автор: GoldFinch 18.4.2010, 23:16

Покажите хоть один вредный совет у Макконнелла.

Автор: kemiisto 19.4.2010, 10:22

Цитата(GoldFinch @  19.4.2010,  00:16 ) Покажите хоть один вредный совет у Макконнелла. Скажем, вот такой пример. В главе 19 идёт достаточно обширное и неплохое изложение струкутурного программирования. Конкретно на стр. 450 написано чёрным по белому: Цитата Я считаю, что использование любых управляющих структур, отличных от этих трех стандартных конструкций, т. е. break, continue, return, throw-catch и т. д., должны рассматриваться под критическим углом зрения. Да, всё верно. НО! Чуть выше, стр. 440 дан совет: Цитата Упростите вложенные if с помощью блока с выходом Альтернативой к только что описанному подходу будет создание фрагмента кода, который будет выполняться как блок. Если одно из условий в середине блока не выполнится, остаток блока будет пропущен. Код: Код do {   // Начало блока с выходом.   if ( inputStatus != InputStatus_Success ) {     break; // Выходим из блока.   }   // Много кода.   if ( printerRoutine == NULL ) {     break; // Выходим из блока.   // Много кода.   if ( !SetupPage() ) {     break; // Выходим из блока.   // Много кода.   if ( !AllocMem( &printData ) )     break; // Выходим из блока.   // Много кода. } while (FALSE); // Конец блока с выходом Во-первых, сам же пишет, что надо относиться критически. А этот код никакой критики не выдержит. Во-вторых, если мне нужно проверить сложное условие, я проверяю сложное условие. А глубоко вложенные if можно переписать через if-elese if. И чуть ниже в следующем совете так и сделано. А когда я вижу цикл, я начинаю думать, "что тут у нас в цикле?" А там...

Автор: GoldFinch 19.4.2010, 11:09

kemiisto,  "должны рассматриваться под критическим углом зрения" не означает "не должны  использоваться" в приведенном куске кода SEME вполне оправдано, и использование break оправдано, хотя возможно тело цикла следовало бы вынести в отдельную функцию и использовать return. единственное что там плохо - это "много кода", это "много кода" должно быть вынесено в отдельные функции. Добавлено через 4 минуты и 20 секунд Цитата(kemiisto @  19.4.2010,  10:22 ) если мне нужно проверить сложное условие, я проверяю сложное условие. А глубоко вложенные if можно переписать через if-elese if там нет сложного условия и возможностей использования if-elese if я так понимаю там Код make_step_1(global_state); if(!step_1_success(global_state))     return; make_step_2(global_state); if(!step_2_success(global_state))     return; .......... make_step_N(global_state); if(!step_N_success(global_state))     return;

Автор: kemiisto 19.4.2010, 11:15

GoldFinch, вот видишь. Ну не понимаешь ты. Дейкстру не читал, пишешь на одних ###языках. Ты как Макконнелл. А рыбак рыбака. Дальнейший смысл в обсуждении отсутствует. Всем чмоки в этом чате!

Автор: GoldFinch 19.4.2010, 11:35

kemiisto,  спасибо, я весьма польщен, не часто меня сравнивают с Макконнеллом Но тогда расскажи что следует читать, и на каких языках следует писать, я вот сейчас пишу на асме, vba, js, C++, немного C#, Python.

Автор: Oxy 20.4.2010, 16:27

Цитата(kemiisto @  18.4.2010,  15:28 ) Начнём с того, что ты задашь этот вопрос Sartorius, чтобы не отклоняться от хронологии событий. нет, именно тебе, я согласен с Цитата(Sartorius @  16.4.2010,  11:34 ) В любом случае must read  ну и что если там не все советы хороши, но ведь есть и хорошие может у Дейкстры или у Вирта все советы хороши? на кол? Цитата(GoldFinch @  19.4.2010,  11:35 ) на каких языках следует писать Oberon

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)