Использование отдельных символов для имен переменных в циклах / исключениях

Question

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

Он предпочитает более подробное соглашение об именах дляэто, а я нет.

По моему мнению, есть три сценария, в которых я использую имена переменных из одной буквы:

• Петли - i for(int i = 0; i < 10; i++) { ... }
• Лямбда-выражения в C # - x/y/z: .Where(x => x == 5)
• Исключения - e: try { ... } catch(ExceptionType e) { /* usage of 'e' */ }

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

Мой коллега выдвинул следующие аргументы для исключений и циклов:

• i - это ничего не значит.
• e - это самая распространенная буква на английском языке.Если вы хотите найти решение для поиска исключений, вы найдете множество нежелательных экземпляров e.

Я принимаю эти аргументы, но у меня есть возражения, если кто-то не знает, что i означает в цикле for, тогда они, вероятно, не должны быть программистом.Это очень распространенный термин для циклов и исключений, как e.Я также упомянул, что, если кто-то хотел, они могли бы искать catch в случае исключения.

Я понимаю, что это субъективно, но тогда можно утверждать, что стандарты кодирования - это просто ...мнения, пусть и мнения академиков.

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

Заранее спасибо.

Answer 1

Если лексическая область действия переменной превышает 20 или 25 строк, то переменная, вероятно, не должна иметь одно буквенное имя. Если большое количество переменных в вашей кодовой базе имеет лексическую область, превышающую 25 строк (или около того), то ваша кодовая база имеет гораздо большую проблему, чем можно решить с помощью подробного соглашения об именах.

Answer 2

i doesn't mean anything

Да, это так. Это индекс для цикла или счетчика.

e is the most common letter in the English language. If you wanted to search the solution for exceptions, you'd find lots of undesired instances of e

Это даже не имеет никакого смысла. Зачем вам искать e, если вы хотите найти экземпляры Exception?

Serioulsy, я бы просто посмеялся над каждым, кто выступил с этими аргументами. Каждый знает, что i и e представляют в этих сценариях. Это общепринятые соглашения . Для меня это звучит так, будто ваш коллега просто пытается быть умником.

Редактировать - Этот вопрос напомнил мне о этом wtf .

Answer 3

Недавно я разговаривал с кем-то об этом.

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

Например, в JavaScript:

myArrayOfNames.forEach ( function ( name ) { } );
myArrayOfNames.map ( function ( name ) { } );
myArrayOfNames.filter ( function ( name ) { } );

Я обычно использую «каждый», «объект» или просто «d» для такого рода вещей, потому что я вижу их как конечноабстракции.«имя» на самом деле не говорит мне ничего, кроме имени из массива имен.

Кому интересно?Потому что я видел, как разработчики повторяют обзоры, спорящие о том, что является «значимым».Больше чем единожды.

Итак, на протяжении многих лет я стремился уладить это, сказав, что операция - это функциональная абстракция (итерация), применяемая к какому-то конкретному списку.Отразите этот язык и использование в вашем коде:

myUsefullyNamedArray.filter ( function ( d ) {
    return ( 'someval' in d ); 
} );

Answer 4

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

Exception yourToys = new Exception(...);
throw yourToys;

или

Exception up_in_a_bucket = new Exception(...);
throw up_in_a_bucket;