Длинные имена слишком длинные

[kinall]

Мы только отказались от Венгерской нотации. Отпусти и забудь</blockquote
Разве отказались?

[1c80]

Ну он может и отказался, его дело.

// Плохо:
mergeTableCells(List cells)
sortEventsUsingComparator(List events,
Comparator comparator)

// Хорошо:
merge(List cells)
sort(List events, Comparator comparator)


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

[Serbin]

Сегодня я встречал её только в embedded разработке ввиду её специфики.

[DSolodukhin]

Разве отказались?

Мы и не начинали.

[Tangeman]

Ещё сильно «радует» явное использование префиксов namespace при использовании достаточно уникальных (и говорящих за себя) имен в C++ (и других языках с namespace) — типа std::string, std::printf и пр. на каждом шагу.

Очень интересно, какая религия не позволяет разрабочику указать «using namespace std» в файле, или даже в пределах scope где std так и пестрит.

[elmirius]

Это делается для того, чтобы явно обозначить использование std-шных контейнеров и алгоритмов в проекте. string, например, далеко не уникальное имя, и очень много где используется своя реализация.

[Tangeman]

Я говорю как раз о случаях когда оно уникально в пределах не то что отдельного файла, а всего проекта, и всегда ссылается на std.

[slonopotamus]

и других языках с namespace

Нет. Контрпример: Java.

[tagir_valeev]

Интересно, часто вы видели в джаве out.println вместо System.out.println со статическим импортом System.out? Ближайший аналог неймспейсов в джаве — это именно статические импорты.

[slonopotamus]

разговор был про неймспейсы. Никто на джаве не пишет java.lang.System.out.println.

[tagir_valeev]

Почему вы отождествляете пакет и неймспейс? Я вот утверждаю, что класс ближе к понятию неймспейс, чем пакет, потому что как и в C++ в классе могут содержаться функции (статические методы), константы (статические поля) и классы (статические вложенные). А в пакете могут быть только классы. Например, в C++ есть std::sprintf, который можно не квалифицировать, если написать using. В Java есть похожий метод java.lang.String::format. Его тоже можно не квалифицировать, используя import static. Но так мало кто делает, все используют квалификатор (пусть и неполный) String.format.

[rjhdby]

Если рассматривать пространство имен как дерево, то классы — это листья.
Я к тому, что спор про то, пакет или класс "ближе" к неймспейсам — это такое… Довольно странное занятие. (а import — это всего лишь изоляция подграфа для удобства работы с ним)

[a1ien_n3t]

Очень хорошо описанно писать или нет using namespace std в C++ Core Guidelines

[Tangeman]

Я понимаю пользу явного указания namespace (в отдельных случаях), но, как я уже сказал выше — речь о случаях когда конфликты практически невозможны.

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

[tcapb1]

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

Например, если это библиотека для работы с изображениями, то имена методов должны быть простыми и однозначными: crop, rotate, resize и т.д. Тогда они логичные и их легко запомнить. Если это будет что-то типа makeImageResize(), то такие имена сложно удержать в памяти, придётся постоянно дёргать документацию или полагаться на автозаполнение, что приведёт к тому, что программисты будут избегать этой библиотеки.

Уже более 10 лет назад примерно на равных соревновались три библиотеки для JavaScript: jQuery, Prototypre.js и Mootools. На мой взгляд, не последнюю роль в выходе jQuery в победители сыграла его лаконичность. Сравните:

$$('.foo').getElement('div.bar') и $('.foo').find('div.bar')
el.addEvent('click', function(){}) и el.on('click', function(){})
$$('.foo').setStyle('width', '300px') и $('.foo').css('width', '300px');

Я в то время пытался использовать MooTools и никак не мог запомнить названия методов, а jQuery зашло моментально, можно было вспомнить что писать чисто по логике.

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

[rjhdby]

Есть и другая крайность — слишком общие названия.
Тот же find — что именно он найдет и вернет? Первый элемент, последний, случайный, конкретный, все подходящие? Что это за элемент будет? getElement — уже лучше, хотя бы понятно, что он будет один.

[Cerberuser]

В этом смысле меня "радует" интерфейс к MongoDB в Node.js, где есть find, который возвращает курсор (по сути, итератор), и есть findOne, который возвращает сразу объект. А ещё там есть findOneAndReplace, а есть replaceOne, которые отличаются, судя по докам, тем, что первая операция атомарна, а вторая — нет. Весело, блин...

[WanSpi]

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