Чи варто префікси типу та сфери застосування доцільно називати конвенціями?

Нещодавно, починаючи свою першу роботу в якості розробника програмного забезпечення, мені трохи закинули, що мені сказали, що я не повинен дотримуватися жодних умов іменування в своєму коді. Кодекс, написаний групами, що працюють над іншими, більшими проектами, дотримувався конвенцій щодо іменування, але, оскільки мене запросили написати нову, автономну заявку, відчуття було, що це особливо не має значення. Це було останнє з моїх турбот, тому я просто взяв ту діючу конвенцію і побіг з нею.

int nTickCount  
bool bConnected  
object[] m_aItems  
fSum += fWeight * fValue  
class cManager  
enum etSystemStates  
etSystemStates eState   
cManager.cs

Але чи насправді це варто? Мені важко судити про чистий ефект того, що слідування такому конвенції про іменування має розуміння та виявлення помилок, але, візуально , це просто виглядає некрасиво. Плюс до того, що кожен клас і файл у проекті під назвою cSomething здається досить асиніним.

Я не відчуваю, що це велика справа в порівнянні з речами, які явно змінюють, як, наприклад, алгоритми та архітектури, які ви використовуєте. Але будь-яка умова, яка впливає на кожен рядок коду, який я пишу, здається, варто правильно.

Що ви вважаєте найелегантнішою та найефективнішою умовою іменування, якщо її взагалі потрібно використовувати? Чи позначає він тип та / або область застосування?

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

Префікси, такі як tbl для таблиці баз даних, int для цілого числа тощо, як правило, не корисні - розробити те, що є з контексту чи з ваших інструментів розробки в цих випадках, тривіально. Щось на зразок імп для імператорських вимірювань і зустрічається для метрики має набагато більше сенсу, тому що в іншому випадку ви можете бачити лише те, що вони є числами з плаваючою комою.

area = width * height

при цьому виглядає прекрасно

impArea = metWidth * impHeight

показує вам відразу, що щось не так.

Особисто я просто використовую описові назви змінних. $ number_of_items, очевидно, ціле число. $ input_file_handle, $ is_active та $ encrypted_password мають очевидні типи як з точки зору мовних даних, так і семантичного типу.

Те, що ви описуєте, називається угорським позначенням . Колись це вважалося найкращою практикою, але зараз, як правило, нахмуриться.

Стаття у Вікіпедії містить розділ про її плюси та мінуси.

Так, префікси можуть бути корисними, але у мене є кілька пропозицій:

Якщо вся ваша команда використовує однакові умови, вони стають набагато кориснішими. Використання їх самостійно є менш корисним.

У сильно статично набраних мовах не просто копіюйте тип змінної. Наприклад, "bSubscribed" - це неправильне ім'я булевої змінної в C # або Java, тому що ваш IDE вже знає, що це тип. З іншого боку, що не має булевого типу, це була б корисна інформація.

У C # та Java ви можете розглянути префікс, який показує, що об’єкт може бути нульовим. Або про те, що рядок відмовився від HTML. Або що це являє собою регулярний вираз, або оператор sql. Або що масив був відсортований. Використовуйте свою фантазію.

По суті, це питання запитати себе, що ви хочете сказати вам ім'я змінної, і це багато що залежить від домену та мови, на якій ви працюєте.

Існує кілька різних «стилів» конвенції іменування, і більшість з них мають певне значення, щоб зробити код зрозумілим.

Що FAR важливіше: використовувати описові імена для змінних та функцій. У вашому прикладі з "сумами", "вагою" та "значеннями" ви можете навести більш значущі назви: "totalCost", "lumberWeight", "lumberValuePerOunce" (я роблю деякі припущення тут)

Я вважаю, що у більшості сучасних мов такі конвенції, як попередження імен змінних із символом, що означає тип, є досить відволікаючими.

Більшість розробників .NET дотримуються принципів дизайну Microsoft ( http://msdn.microsoft.com/en-us/library/ms229042.aspx ), що досить схоже на Java (основна відмінність полягає в тому, що Microsoft надає перевагу Pascal Case для імен членів, тоді як Java надає перевагу справі верблюда).

Крім цього, я б сказав, що ваш зразок коду набагато менш читабельний через додатковий шум, який ви додали.

Я вважаю, що здебільшого посібник зі стилю кодування Google є досить хорошим. Оскільки вам сказали, що ви можете використовувати будь-який стиль, який вам подобається, я думаю, слід почати з перегляду цього, вибору та вибору з нього.

Префіксація назв змінних типів даних (особливо примітивних типів даних) збільшує візуальний шум, а також ризик того, що в іншому випадку невелика зміна стане перейменовуванням великого удару.

По-перше, чи "intStudentCount" справді ясніше, ніж, наприклад, "numberOfStudents"? Не було б "invoiceLineItems" принаймні такою ж інформативною, як "aobjItems". (Тип даних повинен відповідати змісту даних у проблемній області, а не представництві низького рівня.)

Що стосується другого пункту, що відбувається, коли, наприклад, передчасний вибір int замінюється довгим чи подвійним? Ще гірше, що відбувається, коли конкретний клас переробляється на інтерфейс з декількома класами реалізації? Будь-яка практика, яка збільшує тягар реалістичних сценаріїв обслуговування, здається мені сумнівною.

Це також може залежати від того, чому ви префіксуєте ім'я, на відміну від того, з чим ви його префіксом.

Як приклад, я схильний використовувати префікс 1-2 літер для імен елементів управління на формі. Це не тому, що я не знаю, що компілятор легко знайде потрібний клас для кнопки (як приклад), але я схильний спочатку розробити великі форми, а потім написати більшу частину коду.

Наявність префіксу bt для кнопок дозволяє легко знайти потрібну кнопку згодом, замість того, щоб багато імен переплуталися разом.

Я не використовую префікси для іменування змінних, ні для типу (який взагалі не є таким корисним), ні для значення, контексту чи одиниці (що є оригінальною ідеєю угорської нотації).

На мою думку, це залежить від мови та розміру проекту. Я ніколи не пішов так далеко, щоб використовувати префікси типу для всіх моїх змінних, але ви хочете назвати їх чітко.

Статично набраною мовою, як та, якою ви користуєтеся, чим комфортніше я відчуваю систему типу, тим менш важливою стає угорська нотація. Тож у Java чи C #, особливо в Haskell, я б навіть не замислювався над тим, щоб додати ці префікси, тому що ваші інструменти можуть вказати вам тип будь-якого виразу, і вловить більшість помилок внаслідок нерозуміння типу.

Префікси часто мають сенс для об'єктів, наприклад, у формі, де у вас може бути 20 текстових полів, називаючи їх усіма tbSomethingсенсами.

Однак, в основному, я не думаю, що це варто, особливо для типів цінності.

Наприклад, припустимо, у вас були:

short shortValue = 0;
//stuff happens

Через кілька місяців ви побачите, що вам потрібно це змінити - короткий не досить великий. Тепер у вас є:

int shortValue = 0;
//stuff happens

Якщо ви зараз також не зміните ім'я змінної (більше ризику зламати код, ніж змінити тип у цьому випадку), у вас тепер є заплутаний код.

Вам краще мати ім’я, яке описує, що він містить:

int loopCounter = 0;
//stuff happens

Якщо пізніше це потрібно змінити до довгого: немає проблем.

Для цих конвенцій може бути більше аргументів на динамічно набраних мовах або тих, що не мають IDE.

Я завжди був схильний використовувати абревіатуру від 2 до 4 символів для типу перед самою змінною. Часом це здається нудним, але коли ти працюєш зі складними типами даних або ситуаціями, це стає корисним. Я думаю, що він належить до нижньої категорії корпусу верблюдів.

Дивлячись на ваш приклад вище, було б трохи перероблено:

int intTickCount;
bool boolConnected;
object[] aobjItems;

Масиви завжди мають a перед типом для позначення масиву. Це також дозволяє мені групувати подібні екземпляри змінних разом. Наприклад, я можу використовувати ...

taStore.Fill(dtStore);

... що вказує на те, що мій табличний адаптер магазину заповнюється у Data Dataable магазину.

Я завжди намагався дотримуватися основного принципу, що префікси та / або суфікси слід вставляти лише тоді, коли це зробить код більш читабельним (як у звичайній англійській мові).

Чим менше криптовалют, тим краще ...

Чому потрібен такий метод:

public boolean connect( String h, int p );

Коли ви можете мати щось подібне:

public boolean connect( String hostName, int port );

Більше того, сьогодні IDE дійсно мають потужний інструмент для рефакторингу змінних (особливо Java) змінних, назв методів, класів тощо ... Ідея сказати максимальну інформацію з найменшою кількістю символів просто старомодна.