Доброго времени суток!

Мне одному кажется что современные IDE развиваются не в том направлении?
Все эти мастера, сниппеты, контекстные подсказки и прочие радости сомнительного харрактера иногда мешают что называется просто писать код.
Может вместо этого разработчикам IDE обратить свой взгляд на более важные имхо вещи:
1. Очень простая в использовании система локализации ПО
2. Очень простая в использовании система создания инсталяторов
3. Очень простая в использовании система управления версиями
4. Очень простая в использовании система для управления совместимостью
... вообщем на то,что связано скорее с поддержкой и распространением ПО нежели с его написанием — с написанием программист как то и сам справится, а вот поддержка и распространиние это имхо и есть самый "головняк" для программиста.
Ваше мнение? Может кто то юзал IDE где такой функционал присутствует не в зачаточном состоянии?

Здравствуйте, skeptic, Вы писали:

S>Мне одному кажется что современные IDE развиваются не в том направлении?
S>Все эти мастера, сниппеты, контекстные подсказки и прочие радости сомнительного харрактера иногда мешают что называется просто писать код.
Ну вот мне например VAX код писать помогает.

S>Может вместо этого разработчикам IDE обратить свой взгляд на более важные имхо вещи:
S>1. Очень простая в использовании система локализации ПО
Не очень себе представляю как полноценную локализаторскую систему можно встроить в IDE? А неполноценные встроенные нафиг не нужны.

S>2. Очень простая в использовании система создания инсталяторов
А какое отношение создание инсталлятора имеет к написанию кода? И какой инсталлятор должна создавать IDE?
Вот мы например вообще со следующего релиза одного серверного продукта отказываемся от MSI в пользу самописного инсталлятора. Ибо борьба с "особенностями" MSI задрала.

S>3. Очень простая в использовании система управления версиями
Т.е. yet another VCS, integrated into IDE? Уже имели такое в виде VSS, уж лучше пусть будет Tortoise SVN в explorer context menu.

S>4. Очень простая в использовании система для управления совместимостью
Совместимостью чего с чем?

S>... вообщем на то,что связано скорее с поддержкой и распространением ПО нежели с его написанием — с написанием программист как то и сам справится, а вот поддержка и распространиние это имхо и есть самый "головняк" для программиста.
Непонятно зачем этот функционал встраивать в IDE?

Здравствуйте, skeptic, Вы писали:

S>Все эти мастера, сниппеты, контекстные подсказки и прочие радости сомнительного харрактера иногда мешают что называется просто писать код.
Сильно зависит от языка/IDE.

S>1. Очень простая в использовании система локализации ПО
Почти всегда перевод отдают профессиональным локализаторам; локализуемые ресурсы сильно зависят от используемового фреймворка. Но да, общий формат для экспорта не помешал бы.

S>2. Очень простая в использовании система создания инсталяторов
Ага. Инсталлятор в студии кошмарен

S>3. Очень простая в использовании система управления версиями
Для студии — анк. Увы, сам свн кошмарен до неприличия, а остальные коммунити больше заняты ЧСВ, чем удобством работы.

S>4. Очень простая в использовании система для управления совместимостью
Не понял

Я бы добавил легковесный таск трекер с автоматическим бранчем/мержем на каждую фичу + wiki + интеграция с создаваемой справкой. Только не набор "Вы можете настроить всё. И будете.", а "поставил и оно работает".

Здравствуйте, CreatorCray, Вы писали:

CC>Непонятно зачем этот функционал встраивать в IDE?
Чтобы не тыкаться между зоопарком софтин, каждой из которых положить и на интеграцию, и на удобство использования. Чем проще пользоваться таким побочным софтом — тем лучше.

Здравствуйте, skeptic, Вы писали:

S>Доброго времени суток!

S>Мне одному кажется что современные IDE развиваются не в том направлении?
мир не ограничивается ms vs. а куда развивается ms -- тема отдельного разговора. кстати, а вы пробовали программировать без ide? в частности, зачем вам один-единственный встроенный отладчик, если можно взять любой другой по вкусу? тоже самое про систему контроля версий.

грустно видеть как мир приходит к тому, что IDE подменяет язык программирования.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, skeptic, Вы писали:


S>Я бы добавил легковесный таск трекер с автоматическим бранчем/мержем на каждую фичу + wiki + интеграция с создаваемой справкой. Только не набор "Вы можете настроить всё. И будете.", а "поставил и оно работает".

Вот, вот про это я и говорил, тут высказались уже из серии "никто не нужен" и "пишите в far'е/vim'е/emacs'е — ненужное закидать какашками" и "даёшь больше тулзовин хороших и разных!".Это всё хорошо, выбор там, всякие интересный штуки, но как достало уже все эти интересные штуки дружить друг с дружкой в то время когда каждая из них считает себя д'артаньяном. Про совместимость я имел ввиду например избавление разработчика от головной боли связанной со всякими манифестами, версиями сишных рантаймов и т.д, что бы было всё очень просто и понятно, сейчас меня наверное закидают помидорами всякие труъ-кодеры но вот что то такое я и хотел бы видеть в современных IDE. Вообщем всё что я написал это сумбур и абстракция, главный посыл — избавить разраба от всяких побочных проблем не связанных напрямую с разрабатываемым функционалом, вот как то так.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, skeptic, Вы писали:

S>>Доброго времени суток!

S>>Мне одному кажется что современные IDE развиваются не в том направлении?
М>мир не ограничивается ms vs. а куда развивается ms -- тема отдельного разговора. кстати, а вы пробовали программировать без ide? в частности, зачем вам один-единственный встроенный отладчик, если можно взять любой другой по вкусу? тоже самое про систему контроля версий.

Казалось бы, при чём тут ms?
Я говорил про IDE, если такую IDE разработает кто то под названием "не-майкрософт" я с удовльствием пересяду и забуду дорогу к msvc.
В то время как к тем фичам которые я перечислил msvc вообще никакого отношения не имеет по одной простой причине — она им не удовлетворяет, да и как я уже говорил ранее я вообще не встречал такой IDE. Мне не нужен самогонный аппарат с стамульёнами ручек,переключателей,тумблеров и автоматической вызывалкой секритуток, мне нужен такой который производит самогон, желательно с минимальным моим участием — это что касается встроенного отладчика по вкусу и системы контроля версий. Без IDE я вполне себе программировал и ничего в этом страшного не вижу, впрочем удобного я в этом тоже ни чего не вижу, а уж быстрого и тем более, впрочем, на вкус и цвет фломастеры как известно у всех разные.

М>грустно видеть как мир приходит к тому, что IDE подменяет язык программирования.

мыщъх, не старайтесь казаться старше и мудрее чем вы есть на самом деле.

Здравствуйте, skeptic, Вы писали:

S>Здравствуйте, мыщъх, Вы писали:

S>Казалось бы, при чём тут ms?
потому что это происки идеологии ms -- собрать разнородные инструменты в кучу. есть компилятор, есть линкер, есть текстовой редактор, есть система контроля версий. кстати, помимо make/nmake тоже много чего есть -- достаточно взглянуть как собирают горячего лиса, google v8 и другие крупные проекты. там совсем другая философия и там можно работать с проектом хоть на линухе, хоть на маке, хоть на винде.

S>Я говорил про IDE, если такую IDE разработает кто то под названием "не-майкрософт" я с удовльствием пересяду
вы пересядете, а я нет. вопрос как быть и что делать, если нам придется работать вместе? видимо, все-таки необходимо прийти к пониманию, что системы контроля версий, тулзы для сборки проекта, а так же многое-многое другое это не часть IDE, а очень сильно сбоку. а вот "сахар" типа автодополнения, цветовой раскраски -- это пожалуйста. это у каждого может быть свое, но и тут грабли в виде тех же табов, например.

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

S> Мне не нужен самогонный аппарат с стамульёнами ручек,переключателей,тумблеров и автоматической
S> вызывалкой секритуток, мне нужен такой который производит самогон, желательно с минимальным моим участием
не совсем понятно... сборка проекта -- make и пошли пить кофе. написание проекта -- если убрать автогенераторы, то разница между "блокнотом" и самой навороченной IDE не так уж и велика и никакая IDE писать код за вас не будет, ибо зачем тогда вы, если это можно сделать и без вашего участия?!

> это что касается встроенного отладчика по вкусу и системы контроля версий.
> Без IDE я вполне себе программировал и ничего в этом страшного не вижу,
> впрочем удобного я в этом тоже ни чего не вижу, а уж быстрого и тем более,
все равно не понимаю разницы. запустить make с отладочной целью это _быстрее_ чем сменить release -> debug в большинстве IDE. далее -- отладчики бывают разные. и интерактивная отладка нужна тем, кто не хочет думать. и помимо нее существуют еще верификаторы кода, утилиты для поиска утечек памяти и стрессовых нагрузок, профилировщики...

М>>грустно видеть как мир приходит к тому, что IDE подменяет язык программирования.
S>мыщъх, не старайтесь казаться старше и мудрее чем вы есть на самом деле.
я и не стараюсь. я молодой и глупый. и это все знают.

Здравствуйте, мыщъх, Вы писали:

М>с другой стороны -- покажи мне свой сорец и я скажу что у тебя за IDE. у меня IDE -- это фар. автодополнения там нет. даже списка функций он не показывает.

Как же так? Cyberax же недавно утверждал, что Фар чуть ли не круче Вима.

Здравствуйте, Don Reba, Вы писали:

DR>Здравствуйте, мыщъх, Вы писали:

М>>с другой стороны -- покажи мне свой сорец и я скажу что у тебя за IDE. у меня IDE -- это фар. автодополнения там нет. даже списка функций он не показывает.
DR>Как же так? Cyberax же недавно утверждал, что Фар чуть ли не круче Вима.
не, ну показывает. даже в колорере есть такая фича, не говоря за другие плагины, но я как-то этим не пользуюсь. а если бы и пользовался -- оно бы мне не помогло, т.к. основное время (во всяком случае у меня) уходит на решение алгоритмических задач, которые вообще решаются на бумаге.

Здравствуйте, мыщъх, Вы писали:



М>у меня все имена короткие, но выбираются так, чтобы их было максимально легко запомнить. и я прихожу в ужас при работе с кодом где имена из сотни символов и функии с десятками аргументов.
Это у вас преувеличение такое, или такой идиотизм и правда встречается? У меня вот имена функций в среднем около 10 символов, по 2-3 передаваемых аргумента, хотя чаще один — на ваш взгляд это как, из той же серии? Кстати, было бы интересно глянуть на кусок характерного для вас кода, какой-нибудь небольшой модуль например.

Здравствуйте, skeptic, Вы писали:

S>Мне одному кажется что современные IDE развиваются не в том направлении?

Может и не одному, но уверен, что большинству так не кажется.

S>Все эти мастера, сниппеты, контекстные подсказки и прочие радости сомнительного харрактера иногда мешают что называется просто писать код.

Попросту долбить буквы еще не значит просто (в смысле без напряга) писать, и тем более, править код.

S>Может вместо этого разработчикам IDE обратить свой взгляд на более важные имхо вещи:
S>1. Очень простая в использовании система локализации ПО
S>2. Очень простая в использовании система создания инсталяторов
S>3. Очень простая в использовании система управления версиями
S>4. Очень простая в использовании система для управления совместимостью

Вот как раз описанные вещи мне в IDE не особо то и нужны. Хотя мешать не будут, конечно. Локализация ПО — это вообще не задача IDE. Создавать инсталляторы можно и без IDE или в отдельной IDE. Кроме того та же VS это делать позволяет. Есть и простенький встроенный проект инсталлятора, и не очень визуальный, но мощный и удобный Wix.
Управление версиями тоже встроено, но лично я предпочитаю SVN через ТоталКомандер. Что за хрень пункт 4 я даже не понял.

S>... вообщем на то,что связано скорее с поддержкой и распространением ПО нежели с его написанием — с написанием программист как то и сам справится, а вот поддержка и распространиние это имхо и есть самый "головняк" для программиста.

Дык может ты просто перепутал продукты? IDE на для создания ПО предназначена, а не для распространения.

S>Ваше мнение? Может кто то юзал IDE где такой функционал присутствует не в зачаточном состоянии?

В VS большая часть перечисленного есть.

Здравствуйте, мыщъх, Вы писали:

М>мир не ограничивается ms vs. а куда развивается ms -- тема отдельного разговора. кстати, а вы пробовали программировать без ide? в частности, зачем вам один-единственный встроенный отладчик, если можно взять любой другой по вкусу? тоже самое про систему контроля версий.
Лично я пробовал программировать без IDE, причем больше года. Скорость разработки была меньше раз в 10, ошибок делал черти сколько, да еще и в памяти держать до черта нужно. Да и даже с IDE. За счет лучшей IDE у меня скорость разработки раз в 5 больше, чем у тех, которые сидят на хреновой IDE, да еще и ошибок меньше делаю. Черти какие рефакторинги делал на время в режиме аврала (спасибо продажникам, блин, умудрились толкнуть то, чего нет — пришлось с бешенной скороростью недостающее реализовывать) — практически без ошибок. В блокноте б неделю сидел. За счет нормального IDE даже в условиях нехватки времени не допускаю копипаста, никогда не забываю заливать файлы в репозиторий, сабмит идет всегда единым ченж листом, билд не ломается. Времени экономится немеряно.

Здравствуйте, dZentle_man, Вы писали:

Z_>Здравствуйте, мыщъх, Вы писали:

М>>у меня все имена короткие, но выбираются так, чтобы их было максимально легко запомнить. и я прихожу в ужас при работе с кодом где имена из сотни символов и функии с десятками аргументов.
Z_>Это у вас преувеличение такое, или такой идиотизм и правда встречается?
открываю наугад. ага, вот Google v8, handles.h вижу

Handle<Object> LookupSingleCharacterStringFromCode(uint32_t index);
void SetExpectedNofPropertiesFromEstimate(Handle<SharedFunctionInfo> shared,
                                          int estimate);
OptimizedObjectForAddingMultipleProperties(Handle<JSObject> object,
                                             int expected_property_count,
                                             bool condition = true);

с одной стороны читать такое приятно, но вот набирать...

> У меня вот имена функций в среднем около 10 символов,
> по 2-3 передаваемых аргумента, хотя чаще один — на ваш взгляд это как, из той же серии?
2-3 аргумента хороши тем (а один еще лучше), что скорее всего их порядок достаточно предсказуем и не нужно каждый раз смотреть в прототим. скажем, если у нас есть источник/приемник, длина и флаги, то ясно, что флаги это не первый аргумент а вот CreateFile без подсказки лично я не напишу.










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

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, мыщъх, Вы писали:


> В блокноте б неделю сидел. За счет нормального IDE даже в условиях нехватки времени не допускаю копипаста,
> никогда не забываю заливать файлы в репозиторий, сабмит идет всегда единым ченж листом, билд не ломается.
> Времени экономится немеряно.
я ж не предлагю все делать руками... но в упор не вижу разницы между запуском внешнего скрипта, который называется, скажем, up.bat и нажатием кнопки, которая все это самбитит прямо в IDE.

кстати, у git'а есть клевая интеграция с проводником винды. рекомендую заценить. правда, сам не юзаю, т.к. сижу в консольном фаре.

Здравствуйте, мыщъх, Вы писали:




М>>>у меня все имена короткие, но выбираются так, чтобы их было максимально легко запомнить. и я прихожу в ужас при работе с кодом где имена из сотни символов и функии с десятками аргументов.
Z_>>Это у вас преувеличение такое, или такой идиотизм и правда встречается?
М>открываю наугад. ага, вот Google v8, handles.h вижу

М>

М>Handle<Object> LookupSingleCharacterStringFromCode(uint32_t index);
М>void SetExpectedNofPropertiesFromEstimate(Handle<SharedFunctionInfo> shared,
М>                                          int estimate);
М>OptimizedObjectForAddingMultipleProperties(Handle<JSObject> object,
М>                                             int expected_property_count,
М>                                             bool condition = true);

М>

М>с одной стороны читать такое приятно, но вот набирать...
Ну хоть не 100 символов, а порядка 30) Но тут даже с точки зрения чтения можно докопаться — пока всю эту строку прочитаешь, уже и день пройдет. Вполне можно было сократить Character до Char, Single — выкинуть, про String не упоминать вовсе, и FromCode — тоже достаточно сомнительной ценности в плане информативности. Что осталось бы? LookupChar — вполне удобное название, и из нормального контекста вполне можно понять что оно и зачем, а такие уточняющие лейблы как FromCode — это если у нас несколько типичных функций для разных нужд. То есть, конечно, для нормально читаемого кода нужно еще и логичный, читаемый контекст писать, а не только тупо разжевывать и переваривать имена функций, потому что если увлечься и переварить, то результат варения известен же...)


>> У меня вот имена функций в среднем около 10 символов,
>> по 2-3 передаваемых аргумента, хотя чаще один — на ваш взгляд это как, из той же серии?
М>2-3 аргумента хороши тем (а один еще лучше), что скорее всего их порядок достаточно предсказуем и не нужно каждый раз смотреть в прототим. скажем, если у нас есть источник/приемник, длина и флаги, то ясно, что флаги это не первый аргумент
Угу, это что касается стандартной типизации, которая в нормальной архитектуре должна быть конечно предусмотрена и часто, если нет особых причин против, полезно чтобы она походила на другие архитектуры — чтобы быстрее можно было вникнуть и меньше насиловать мозг под новые понятия.


М> Кстати, было бы интересно глянуть на кусок характерного для вас кода, какой-нибудь небольшой модуль например.
А это я не понял — вы просто забыли ответить или не давая своих примеров просите показать мои?)

Здравствуйте, мыщъх, Вы писали:

М>я ж не предлагю все делать руками... но в упор не вижу разницы между запуском внешнего скрипта, который называется, скажем, up.bat и нажатием кнопки, которая все это самбитит прямо в IDE.
М>кстати, у git'а есть клевая интеграция с проводником винды. рекомендую заценить. правда, сам не юзаю, т.к. сижу в консольном фаре.
Отстой эта вся интеграция с проводником, что там смотреть . Вот типичный сценарий использования IDE — занимаюсь какой то фичей, вдруг потребовалось срочно сделать другую. Я старые измененные файлы переношу в новый ченжлист delayed, и на время забываю. Работаю над новой фичей — любое мое изменение автоматом помещается в ченжлист default. Закончил фичу срочную — коммичу ченжлист default, коммит идет атомарный, и продолжаю работать над старой фичей, перенеся все файлы из ченжлиста delayed в default. Если кто то засабмитил в репозиторий, я до апдейта и сабмита вижу, что были изменения, и я оперативно забираю изменения с репозитория — вероятность того, что придется мержить, минимальна. Да, IDE мне сама подсвечивает те места в коде, что я изменял, я могу легко посмотреть что было до этого, не вызывая диффилку. Сабмит делаю как можно чаще, делаю все постепенно, вероятность того, что я что то сломаю — коайне невелика. Если надо — быстро откачусь.
И еще, мне пофиг что за VCS я использую, хоть git, хоть CVS, хоть SVN, хоть Perforce — для меня разницы не будет, я буду работать, как и раньше. Да, кстати, мне еще и на ОС, под которой работать, глубоко плевать, хоть на винде, хоть на маке, хоть на линуксе — разницы практически нет .

Здравствуйте, dZentle_man, Вы писали:

Z_>Здравствуйте, мыщъх, Вы писали:

М>>с одной стороны читать такое приятно, но вот набирать...
Z_>Ну хоть не 100 символов, а порядка 30)
так это не самый плохой пример. все-таки гугл, а не студенческое творчество.

Z_> Но тут даже с точки зрения чтения можно докопаться — пока всю эту строку прочитаешь, уже и день пройдет.
это от незнания eng снижение скорости чтения главным происходит из-за "распухания" листинга и уменьшения информационной плотности. не влезает на экран и приходится гонять код взад — вперед. невозможно просто "окинуть" взгядом...

Z_> Вполне можно было сократить Character до Char, Single — выкинуть, про String не упоминать вовсе,
а char до chr string так же сокращается до str, причем это общепринятые сокращения, над которыми не нужно ломать голову. а то ведь можно и до c и s сократить

> То есть, конечно, для нормально читаемого кода нужно еще и логичный, читаемый контекст писать,
> а не только тупо разжевывать и переваривать имена функций, потому что если увлечься и переварить,
> то результат варения известен же...)
удачное имя функции избаляет от необходимости смотреть ее имплементацию но выбрать удачное название сложно. скажем, если у нас есть функция конвертации числа из строки в целочисленный тип, то FromString явно лишее, т.к. это и так следует из аргумента. с другой стороны ToInt/Long тоже лишее, ибо это тоже следует из арумента но если написать int x = .("123"), то ни разу не понятно, что это мы делаем. может длину берем. кстати, на многих языках такой функции и нет, т.к. язык сам поймет если слева целочисленный тип, а справа строка -- то конвертируем. впрочем, на си функция atol очень даже рулит и являет собой пример хорошего названия.

Здравствуйте, мыщъх, Вы писали:



М>>>с одной стороны читать такое приятно, но вот набирать...
Z_>>Ну хоть не 100 символов, а порядка 30)
М>так это не самый плохой пример. все-таки гугл, а не студенческое творчество.
Да по ходу студенты и писали, только работающие в гугле) Ну или студенты выросли, а мозг студенческий остался)


Z_>> Но тут даже с точки зрения чтения можно докопаться — пока всю эту строку прочитаешь, уже и день пройдет.
М>это от незнания eng
Та я с удовольствием на инглише читаю) Нет, тут дело в том, что 8-10-12-буквенное сочетание можно мельком окинуть взглядом первые 3-4 и последние 3-4 буквы и додумать что внутри, особенно когда один раз эту функцию в коде уже видел. А 32-буквенное сочетание нужно прочитать от и до, потому что "мало ли там какое окончание, которое меняет весь смысл", причем при чтении такого длинного слова сходу ухватываешь только первую его половину, а когда слово уже казалось бы давно должно было кончиться — приходится через силу заставлять себя дочитать до конца и еще и проанализировать весь этот словопоток. То есть, теоретически, мы получаем довольно хорошее представление что эта функция делает. На практике же разбираться в хренотипе функции приходится далеко не всегда, и далеко не в каждой, а только в интересующих местах. Например если взять название функции LookupChar, то очевидно же, что откуда то каким-то образом берется Char, причем если допустить что берется он правильно и как надо, то можно спокойно дальше читать листинг, потратив лишь миг своего времени на осознание присутствия этой функции, а если весь листинг из длинных имен, то чтобы прочитать хотя бы его фрагмент — нужно тратить дополнительное время на чтение и анализ при простом, даже поверхностном чтении.


М>снижение скорости чтения главным происходит из-за "распухания" листинга и уменьшения информационной плотности. не влезает на экран и приходится гонять код взад — вперед. невозможно просто "окинуть" взгядом...
Настоящее распухание начинается когди эти функции используются внутри выражений. Кстати, как они в своих IDE выкручиваются из таких ситуаций с горизонтальной прокруткой — это ж надо специальные кнопки жать, помнить состояние соседнего по горизонтали экрана... Тут уже никакая IDE не поможет. Ах вот оно почему широкие экраны так популярны и диагональ аж за 30 дюймов переваливает)))


Z_>> Вполне можно было сократить Character до Char, Single — выкинуть, про String не упоминать вовсе,
М>а char до chr
Ну нет, это уже перегиб в обратную сторону, тут нужно чувство меры — именно оно и определяет комфортность получаемого листинга. Вот скажем Char — очень распространенный тип, который сложно с чем-нибудь перепутать, особенно программисту — вот вы например разве подумали бы о чем-нибудь другом, если бы встретили Char в имени функции? А вот chr вполне может оказаться каким-нибудь сокращением, с вероятностью процентов на 30 — и уже приходится допускать ее и прикидывать стоит ли идти и посмотреть прототип функции на всякий случай. А char — он и есть char, со всей 90-процентной вероятностью.


>> То есть, конечно, для нормально читаемого кода нужно еще и логичный, читаемый контекст писать,
>> а не только тупо разжевывать и переваривать имена функций, потому что если увлечься и переварить,
>> то результат варения известен же...)
М>удачное имя функции избаляет от необходимости смотреть ее имплементацию
А если бы вы встретили LookupChar вместо LookupSingleCharacterStringFromCode — вам захотелось бы оторваться от последовательного чтения и полезть в документацию? Понятно, что если бы у вас закралось подозрение что где то в этой секции кода зарыт баг, то вы бы проверили все, но а если нет? Мы же тут не художественную литературу читаем, при чтении листинга важно по-быстрому ухватить что здесь происходит вообще, а не восхищаться насколько мы ближе(но окончательно ведь все равно не достигаем) к пониманию истинной сути происходящего от применения огромных имен. То есть два огня — если сильно коротко, то надо додумывать над расшифровкой, а если длинно — то надо много читать и анализировать все слова из имени, приводя к более короткой форме. Золотое сечение подобрать сложно, и без недостатков ни один проект не обходится, но можно по-крайней мере довольно близко к этому подойти.


М>но выбрать удачное название сложно.
А мы и не передадим весь смысл через название — нам нужно подобрать наиболее оптимальный ярлык — где-то есть смысл сделать упор на читабельность, а где-то на передачу смысла. Например GetChar я бы не стал удлинять до GetCharacter, а вот GetHippopotam я бы оставил целиком, не сокращая даже до GetHippo, потому что нормальному программисту наверняка такие функции нигде не могли встречаться)


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

Здравствуйте, мыщъх, Вы писали:

М>удачное имя функции избаляет от необходимости смотреть ее имплементацию но выбрать удачное название сложно.
Привет К.О.

М> скажем, если у нас есть функция конвертации числа из строки в целочисленный тип, то FromString явно лишее, т.к. это и так следует из аргумента. с другой стороны ToInt/Long тоже лишее, ибо это тоже следует из арумента
Из какого аргумента

М>но если написать int x = .("123"), то ни разу не понятно, что это мы делаем. может длину берем.
Правильный вариант int.Prase("123").

М>кстати, на многих языках такой функции и нет, т.к. язык сам поймет если слева целочисленный тип, а справа строка -- то конвертируем.
За такую самодейтельность авторов языков нужно убивать нахрен.

М>впрочем, на си функция atol очень даже рулит и являет собой пример хорошего названия.
И за такие имена то же.