Постоянное злоупотребление?

Вы можете увидеть что-то подобное в кроссплатформенной ситуации, когда вы использовали бы файл с набором констант, соответствующих платформе. Но, вероятно, не на этих реальных примерах. Похоже, кодировщик COBOL пытался сделать свой C # более похожим на английский (без оскорблений для программистов COBOL).

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

Если ноль означает что-то отличное от нуля (в данном случае STRINGS_ARE_EQUAL), то это ВОЛШЕБНО. Создание константы для нее приемлемо и делает код более читабельным.

Создание константы с именем ZERO бессмысленно и напрасная трата энергии пальцев!

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

Например, MATLAB является одноиндексированным, поэтому я могу представить, что кому-то надоедает делать одноразовые ошибки всякий раз, когда они переключают языки, и определять DEFAULT_INDEX в программах C ++ и MATLAB, чтобы абстрагировать разницу. Не обязательно элегантно, но если это то, что нужно ...

Is this code something in your office or something you downloaded?

If it's in the office, I think it's a problem with management if people are randomly placing constants around. Globally, there shouldn't be any constants unless everyone has a clear idea or agreement of what those constants are used for.

In C# ideally you'd want to create a class that holds constants that are used globally by every other class. For example,

class MathConstants
{
 public const int ZERO=0;
}

Then in later classes something like:

....
if(something==MathConstants.ZERO)
...

At least that's how I see it. This way everyone can understand what those constants are without even reading anything else. It would reduce confusion.

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

Смысл в том, чтобы избегать магических чисел , а нули на самом деле не являются магическими.

I think sometimes people blindly follow 'Coding standards' which say "Don't use hardcoded values, define them as constants so that it's easier to manage the code when it needs to be updated' - which is fair enough for stuff like:

const in MAX_NUMBER_OF_ELEMENTS_I_WILL_ALLOW = 100

But does not make sense for:

if(str1.CompareTo(str2) == STRINGS_ARE_EQUAL)

Because everytime I see this code I need to search for what STRINGS_ARE_EQUAL is defined as and then check with docs if that is correct.

Instead if I see:

if(str1.CompareTo(str2) == 0)

I skip step 1 (search what STRINGS_ARE... is defined as) and can check specs for what value 0 means.

You would correctly feel like replacing this with Equals() and use CompareTo() in cases where you are interested in more that just one case, e.g.:

switch (bla.CompareTo(bla1))
{
     case IS_EQUAL:
     case IS_SMALLER:
     case IS_BIGGER:
     default:
}

using if/else statements if appropriate (no idea what CompareTo() returns ...)

I would still check if you defined the values correctly according to specs.

This is of course different if the specs defines something like ComparisonClass::StringsAreEqual value or something like that (I've just made that one up) then you would not use 0 but the appropriate variable.

So it depends, when you specifically need to access first element in array arr[0] is better than arr[FIRST_ELEMENT] because I will still go and check what you have defined as FIRST_ELEMENT because I will not trust you and it might be something different than 0 - for example your 0 element is dud and the real first element is stored at 1 - who knows.

Вы должны взглянуть на некоторые вещи на thedailywtf

One2Pt20462262185th

и

Enterprise SQL

Обычно я могу придумать четыре причины для использования константы:

1. В качестве замены значения, которое может измениться в разумных пределах в будущем (например, IdColumnNumber = 1 ).
2. Как метка для значения, которое может быть непростым для понимания или значимым само по себе (например, FirstAsciiLetter = 65 ),
3. Как более короткий и менее подверженный ошибкам способ ввода длинного или сложного для ввода значения (например, LongSongTitle = "Supercalifragilisticexpialidocious" )
4. В качестве вспомогательного средства памяти для значения, которое трудно запомнить (например, PI = 3.14159265 )

Для ваших конкретных примеров я бы оценил каждый пример следующим образом:

const int ZERO_RECORDS = 0;
// almost definitely a code smell

const int FIRST_ROW = 0;
// first row could be 1 or 0, so this potentially fits reason #2,
// however, doesn't make much sense for standard .NET collections
// because they are always zero-based

const int DEFAULT_INDEX = 0;
// this fits reason #2, possibly #1

const int STRINGS_ARE_EQUAL = 0;
// this very nicely fits reason #2, possibly #4
// (at least for anyone not intimately familiar with string.CompareTo())

Итак, я бы сказал, что нет, они не хуже, чем Zero = 0 или A = "A" .

Это определенно плохое кодирование.

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

Кроме того, для магических чисел ноль не должен быть включен.

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

//input is FIELD_xxx where xxx is a number
input.SubString(LENGTH_OF_FIELD_NAME); //cut out the FIELD_ to give us the number

Я не к месту думаю, что это запах кода? Я чувствую, что это не намного лучше, чем:

const int ZERO = 0;

const int A = 'A';

Вероятно, немного запаха, но определенно лучше, чем ZERO = 0 и А = 'А'. В первом случае они определяют логические константы, то есть некую абстрактную идею (равенство строк) с конкретной реализацией значения.

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

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

Это определенно запах кода.

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

Я не к месту думаю, что это запах кода? Я считаю, что это не намного лучше, чем:

Сравните следующее:

if(str1.CompareTo(str2) == STRINGS_ARE_EQUAL) ...

с

if(str1.CompareTo(str2) == ZERO) ...
if(str1.CompareTo(str2) == 0) ...

Какой из них имеет более непосредственный смысл?

Я бы пошел на запах кода. Если такие константы необходимы, поместите их в перечисление:

enum StringEquality
{
    Equal,
    NotEqual
}

(Однако я подозреваю, что STRINGS_ARE_EQUAL - это то, что возвращает string.Compare , поэтому взломайте его, чтобы вернуть перечисление может быть еще более подробным.)

Изменить: Также SHOUTING_CASE не является особенно соглашением об именах в стиле .NET .

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

const int FIRST_ROW = 0 не имеет смысла.

const int MINIMUM_WIDGET_COUNT = 0 имеет больше смысла.

Предположение, что вы должны следовать стандарту кодирования, имеет смысл. (То есть стандарты кодирования предположительно верны внутри организации.) Рабское следование им, когда предположение не выполняется, не имеет смысла.

Итак, я согласен с более ранними сообщениями о том, что некоторые из вонючих констант, вероятно, возникли в результате следования стандарт кодирования («нет магических чисел») для букв без исключения. Вот в чем проблема.