Доброго времени суток. Надеюсь не ошибся разделом...

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

Простой пример. Есть класс, ну пусть, коллекция машин: CarCollection. В него вносят свойство CarsCount, которое возвращает количество машин в коллекции. Мне кажется, правильнее было бы оставить просто Count, ведь оно и так "машин", но даже если и оставлять связь с сущностью, то общепринятым считается скорее CarCount, без множественного числа. Причем настораживает не только эти два момента, но и то, что со временем в проекте появляется BusCollection, в котором другой программист делает BusCount, а потом TruckCollection, где некто третий добавляет TruckCollectionCount и т.д.

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

Ну, или, как я уже упоминал, возможно проблема во мне и надо смотреть на жизнь проще

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

MK>Доброго времени суток. Надеюсь не ошибся разделом...

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

MK>Простой пример. Есть класс, ну пусть, коллекция машин: CarCollection. В него вносят свойство CarsCount, которое возвращает количество машин в коллекции. Мне кажется, правильнее было бы оставить просто Count, ведь оно и так "машин", но даже если и оставлять связь с сущностью, то общепринятым считается скорее CarCount, без множественного числа. Причем настораживает не только эти два момента, но и то, что со временем в проекте появляется BusCollection, в котором другой программист делает BusCount, а потом TruckCollection, где некто третий добавляет TruckCollectionCount и т.д.

MK>Поэтому и захотелось спросить у форумчан: как бороться с подобными проблемами? Существуют ли какие-то методологии по правильному присвоению имен? Возможно, есть какие-то ресурсы/тулзы, куда можно ввести два три ключевых слова и получить некоторые стандартные грамотные формы. Проблема усугубляется еще и тем, что авторы кода порой чуть ли не рогом упираются: "не буду переименовывать и все". И спасает, пожалуй, только то, что частенько можно в библиотеке .Net найти похожую ситуацию и ткнуть в нее пальцем. Правда потом, этот автор забывает пример и в новых классах появляются все те же "оригинальные" свойства.

MK>Ну, или, как я уже упоминал, возможно проблема во мне и надо смотреть на жизнь проще

Считаю что имя свойства должно быть как хорошее предложение в интуитивном языке. И читать его нужно от первого Namespace. Повторы в таких случаях могут быть оправданны если, призваны отличить два разных свойства.
Например:
...CarCollection.CarsCount
...CarCollection.QueryCount
...CarCollection.OwnersCount
и т.д.
Хотя в случае с Count и ему подобными, они должны наследоватся об базового класса, и тогда я думаю проблема отпадёт сама собой.

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

MK>Доброго времени суток. Надеюсь не ошибся разделом...

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

MK>Простой пример. Есть класс, ну пусть, коллекция машин: CarCollection. В него вносят свойство CarsCount, которое возвращает количество машин в коллекции. Мне кажется, правильнее было бы оставить просто Count, ведь оно и так "машин", но даже если и оставлять связь с сущностью, то общепринятым считается скорее CarCount, без множественного числа. Причем настораживает не только эти два момента, но и то, что со временем в проекте появляется BusCollection, в котором другой программист делает BusCount, а потом TruckCollection, где некто третий добавляет TruckCollectionCount и т.д.

Меня настораживает и другое в том числе: а именно, почему не используются стандартные коллекции? Я уже забыл, когда мне приходилось писать CustomCollection. Но даже если нужно написать свои коллекции, то хорошо бы делать их максимально подобными стандартным и реализовывать стандартные интерфейсы типа ICollection<T>. Вообще, ниужели BusCollection настолько отличается от TruckCollection, что их нельзя обобщить?

MK>Поэтому и захотелось спросить у форумчан: как бороться с подобными проблемами? Существуют ли какие-то методологии по правильному присвоению имен? Возможно, есть какие-то ресурсы/тулзы, куда можно ввести два три ключевых слова и получить некоторые стандартные грамотные формы.
Да, существуют Naming Guideline, правда они не включают в себя английскую грамматику. На счет ресурсов, позволяющих построить стандартные формы — не в курсе. Но на худой конец лучше воспользоваться online переводчиком, чем писать CarsCount или ChildCount.

MK>Проблема усугубляется еще и тем, что авторы кода порой чуть ли не рогом упираются: "не буду переименовывать и все". И спасает, пожалуй, только то, что частенько можно в библиотеке .Net найти похожую ситуацию и ткнуть в нее пальцем. Правда потом, этот автор забывает пример и в новых классах появляются все те же "оригинальные" свойства.

Пинать, пинать и пинать, если позволяет статус. Потом спасибо скажут, если ума хватит

MK>Ну, или, как я уже упоминал, возможно проблема во мне и надо смотреть на жизнь проще

Я за грамотные именования. Такие вопросы надо ставить ребром при разработке.

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

MK>Простой пример. Есть класс, ну пусть, коллекция машин: CarCollection. В него вносят свойство CarsCount, которое возвращает количество машин в коллекции. Мне кажется, правильнее было бы оставить просто Count, ведь оно и так "машин", но даже если и оставлять связь с сущностью, то общепринятым считается скорее CarCount, без множественного числа.

Use CarCount to name the Cars Count. Don't use CarsCount.
Разумеется внутри CarCollection (которую можно назвать просто Cars) логичнее просто Count, если больше никаких счётчиков в ней нет.

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

MK>Мне кажется, правильнее было бы оставить просто Count, ведь оно и так "машин"

Мне тоже. К тому же может наследоваться от списка, а не от коллекции, тогда там уже будет свойство Count, и меньше будет вопросов.

MK>но даже если и оставлять связь с сущностью, то общепринятым считается скорее CarCount, без множественного числа.

Да, правильнее было бы CarCount.

MK>Поэтому и захотелось спросить у форумчан: как бороться с подобными проблемами?

Сесть всем вместе и выработать единую конвенцию именования. Если много разногласий, дать преимущество голоса ведущему и уважаемому разработчику.

MK>Существуют ли какие-то методологии по правильному присвоению имен? Возможно, есть какие-то ресурсы/тулзы, куда можно ввести два три ключевых слова и получить некоторые стандартные грамотные формы.

Лично я обычно не экономлю буквы, с современными IDE и их autocompletion это бессмысленно, зато код потом понятнее. Но случай с Count — это другое, я бы везде называл Count и все. К примеру у вас объект коллекции будет называться cars, тогда будет cars.CarCount — это как-то тупо

MK>Проблема усугубляется еще и тем, что авторы кода порой чуть ли не рогом упираются: "не буду переименовывать и все". И спасает, пожалуй, только то, что частенько можно в библиотеке .Net найти похожую ситуацию и ткнуть в нее пальцем. Правда потом, этот автор забывает пример и в новых классах появляются все те же "оригинальные" свойства.

Как я уже сказал, поможет выработанная в компании конвенция именования. Потом пальцем можно будет тыкать туда, а не искать примеры в .NET.

MK>Ну, или, как я уже упоминал, возможно проблема во мне и надо смотреть на жизнь проще

Да нет, это хорошо что тебе не пофигу, а что стремишься понять как лучше, правильнее.

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

MK> Проблема усугубляется еще и тем, что авторы кода порой чуть ли не рогом упираются: "не буду переименовывать и все".

Это проблема управления. Таких ситуаций не должно возникать.

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

MK>> Проблема усугубляется еще и тем, что авторы кода порой чуть ли не рогом упираются: "не буду переименовывать и все".
M>Это проблема управления. Таких ситуаций не должно возникать.
Искать правильный подход к убеждению или просто быть жестче: "такое имя не годится и всё"?

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

MK>Поэтому и захотелось спросить у форумчан: как бороться с подобными проблемами?

ИМХО, тут две различные проблемы, каждая из которых решается по-своему. Проблема номер раз: "Неизвестно, как _правильно_ называть". Проблема номер два: "Как контролировать соблюдение правильного наименования".

Первая проблема — решите что-нибудь одно и называйте в соответствии со своим решением. Хоть ItemCount, но что бы про любое такое имя можно было бы чётко сказать: оно называется так, потому что… Меня бы лично от всего что угодно кроме "Count" в имени соответствующего свойства коллекции стошнило бы

Вторая проблема — StyleCop и Решарпер смогут помочь. Где не смогут — подсобит процедура ревью.

MK>…но даже если и оставлять связь с сущностью, то общепринятым считается скорее CarCount, без множественного числа.

+1: Имя для метода: GetItem(s)Count?

Автор: _FRED_
Дата: 01.10.08

MK>Существуют ли какие-то методологии по правильному присвоению имен?

Существуют, но не настолько подробные. Ищите FDG. В описанном случае мог бы помочь здравый смысл. Но призвать к нему — задача тяжёлая.

Именование сущностей — вообще задача совсем не такая простая, как многим кажется на первый взгляд. В книге многие такие подводные моменты освещены. Например, namespace нельзя называть так же, как и класс, а вот свойство так же, как и класс называть можно.

MK>Проблема усугубляется еще и тем, что авторы кода порой чуть ли не рогом упираются: "не буду переименовывать и все". И спасает, пожалуй, только то, что частенько можно в библиотеке .Net найти похожую ситуацию и ткнуть в нее пальцем. Правда потом, этот автор забывает пример и в новых классах появляются все те же "оригинальные" свойства.

ИМХО, просто одно из проявлений другой проблемы Косность мышление это или простое упрямство — не знаю но практически неисправимо

MK>Ну, или, как я уже упоминал, возможно проблема во мне и надо смотреть на жизнь проще

Ну, тогда ты не один

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

MK>Поэтому и захотелось спросить у форумчан: как бороться с подобными проблемами? Существуют ли какие-то методологии по правильному присвоению имен? Возможно, есть какие-то ресурсы/тулзы, куда можно ввести два три ключевых слова и получить некоторые стандартные грамотные формы.
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries

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

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

MK>>Простой пример. Есть класс, ну пусть, коллекция машин: CarCollection. В него вносят свойство CarsCount, которое возвращает количество машин в коллекции. Мне кажется, правильнее было бы оставить просто Count, ведь оно и так "машин", но даже если и оставлять связь с сущностью, то общепринятым считается скорее CarCount, без множественного числа.

W>Use CarCount to name the Cars Count. Don't use CarsCount.

А вот это откуда цитата? Поделитесь ссылочкой.

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

MK>>…Существуют ли какие-то методологии по правильному присвоению имен? Возможно, есть какие-то ресурсы/тулзы, куда можно ввести два три ключевых слова и получить некоторые стандартные грамотные формы.
S>Да, существуют Naming Guideline, …

Более современные рекомендации: Guidelines for Names.

Вообще, то что под топиком Design Guidelines for <b>Class Library Developers</b> немного старомодно Более свежие идеи описаны под заголовком Design Guidelines for <b>Developing Class Libraries</b>. Но материал там и там немного отличается и самого пристального изучения достойны обе публикации, тем более с точки зрения прослеживания изменения некоторых формулировок.

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

MK>>> Проблема усугубляется еще и тем, что авторы кода порой чуть ли не рогом упираются: "не буду переименовывать и все".
M>>Это проблема управления. Таких ситуаций не должно возникать.
MK>Искать правильный подход к убеждению или просто быть жестче: "такое имя не годится и всё"?

ИМХО, если не удаётся чётко и неоднозначно сформулировать "правило", то убеждение. Если не помогает — то .

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

S>Меня настораживает и другое в том числе: а именно, почему не используются стандартные коллекции? Я уже забыл, когда мне приходилось писать CustomCollection. Но даже если нужно написать свои коллекции, то хорошо бы делать их максимально подобными стандартным и реализовывать стандартные интерфейсы типа ICollection<T>. Вообще, ниужели BusCollection настолько отличается от TruckCollection, что их нельзя обобщить?
Можно, можно Коллекцию взял для наглядности: часто встречаются и правила общеизвестны. Но по смыслу пример правильный.

MK>>Поэтому и захотелось спросить у форумчан: как бороться с подобными проблемами? Существуют ли какие-то методологии по правильному присвоению имен? Возможно, есть какие-то ресурсы/тулзы, куда можно ввести два три ключевых слова и получить некоторые стандартные грамотные формы.
S>Да, существуют Naming Guideline, правда они не включают в себя английскую грамматику. На счет ресурсов, позволяющих построить стандартные формы — не в курсе. Но на худой конец лучше воспользоваться online переводчиком, чем писать CarsCount или ChildCount.
Это, кстати, неплохая ссылочка, надо будет кинуть линк. А вот грамматика...

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

MK>Это, кстати, неплохая ссылочка, надо будет кинуть линк. А вот грамматика...

Вот ссылка по грамматике этого случая:
http://www.tesol.org/s_tesol/sec_document.asp?CID=647&amp;DID=5082&amp;rcss=print&amp;print=yes

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

_jw>

W>>Use CarCount to name the Cars Count. Don't use CarsCount.

_jw>А вот это откуда цитата? Поделитесь ссылочкой.

Это не цитата, а практическая рекомендация поскольку использование множественного числа ('s') делает имена труднопроизносимыми. Что касается английской грамматики то надо гуглить "compound noun". AFAIK в "compound noun" первое существительное в единственном числе (cf "toothbrush", а не "teethbrush", etc).

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

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

MK>>> Проблема усугубляется еще и тем, что авторы кода порой чуть ли не рогом упираются: "не буду переименовывать и все".
M>>Это проблема управления. Таких ситуаций не должно возникать.

MK>Искать правильный подход к убеждению или просто быть жестче: "такое имя не годится и всё"?

Искать правильный подход к убеждению И "мои требования к именованию ВОТ ТАКИЕ, исправь и старайся в будущем следовать этому стилю"

Если вы отвечаете за качество кода, тогда и вы решаете каким он будет (или делегируете это решение на специалиста).
Если за код несет ответственность специалист, тогда я не понимаю зачем вы вмешиваетесь?

Управляющая должность это в первую очередь принятие ответственности за результат и как инструмент используются более высокие полномочия.

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

MK>Простой пример. Есть класс, ну пусть, коллекция машин: CarCollection. В него вносят свойство CarsCount, которое возвращает количество машин в коллекции. Мне кажется, правильнее было бы оставить просто Count, …

Вот, кстати, и "официальная" рекомендация:

Do use a common name, such as value or item, rather than repeating the type name, in the rare cases when an identifier has no semantic meaning and the type of the parameter is not important.