Как и во многих подобных соглашениях, важно не столько соглашение, которое вы используете, сколько то, что вы используете его последовательно. Например, если у вас есть три служебных класса, и вы называете их CustomerUtil, ProductUtils и StoreUtility, другие люди, пытающиеся использовать ваши классы, будут постоянно путаться и вводить CustomerUtils по ошибке, придется искать их, проклинать вас несколько раз, и т. д. (однажды я услышал лекцию о последовательности, на которой докладчик выложил слайд, на котором показаны наброски его речи с тремя основными пунктами, обозначенными «1», «2-й» и «С».)
Никогда не делайте двух имен, которые отличаются лишь некоторой тонкостью написания, например, имеют CustomerUtil и CustomerUtility. Если для создания двух классов была веская причина, то в них должно быть что-то другое, и название должно, по крайней мере, дать нам понять, в чем заключается это различие. Если одна содержит служебные функции, связанные с именем и адресом, а другая содержит служебные функции, связанные с заказами, то назовите их CustomerNameAndAddressUtil и CustomerOrderUtil или некоторые другие. Я регулярно схожу с ума, когда вижу бессмысленные тонкие различия в именах. Как и вчера, я работал над программой, в которой было три поля для затрат на фрахт, названных «перевозка», «стоимость перевозки» и «доставка». Мне пришлось изучить код, чтобы выяснить, в чем разница между ними.