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

Я работаю с C / C ++ и голосую за Endswith!

«Код написан для чтения людьми и, кстати, запускается компьютерами» SICP

EndsWith FTW !!

Доброта,

Дэн

EndWith стал не только более читаемым, но и более «правильным». Как правило, если для работы предусмотрен метод фреймворка ... используйте его.

Что делать, если foo == string.Empty?

Правила читабельности , особенно если это подразумевает намерение.

В первом примере я должен обнаружить намерение, которое остается для интерпретации. Если кажется, что в нем есть ошибка, как мне узнать, что это не преднамеренно?

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

EndsWith, вероятно, безопаснее. Но индексатор, вероятно, работает быстрее.

Endswith, вероятно, проверяет, пуста ли входная строка. Вероятно, они оба вызовут исключения с нулевой ссылкой. И индексатор выйдет из строя, если длина равна 0.

Что касается удобочитаемости, они оба говорят мне одно и то же, но я уже некоторое время занимаюсь программированием. .EndsWith (...) , вероятно, быстрее понять без учета контекста.

Число 2 лучше читать и хранить. Пример: Проверить последние 2 символа ...

Вариант 1)

if (foo[foo.Length - 1] == 'r' && foo[foo.Length - 2] == 'a')
{

}

Вариант 2)

if (foo.EndsWith("ar"))
{

}

последние 3? последние 4? ...

Оба подхода допустимы, но метод endwith, на мой взгляд, легче читать. Это также устраняет возможность опечаток и т. Д. С помощью более сложной формы.

С точки зрения обработки ошибок EndsWith.

Это примерно то же самое. Однако ситуация усложняется, если в аргументе endwith используется более одного символа. Однако первый пример немного быстрее, поскольку он не использует реальных функций и, следовательно, не требует стека. Возможно, вы захотите определить макрос, который можно использовать, чтобы просто сделать все единообразным.

Лучше всего писать легко читаемый код.Если вы использовали первый, разработчики, отлаживающие ваш код, могут спросить: «Что этот разработчик пытается сделать?» Вам нужно использовать методы, которые легко объяснимы. Если метод слишком сложен для понимания, уберите из него несколько методов.

Я бы определенно сказал, что второе, удобочитаемость и простота являются ключевыми!

Кроме того, если оператор «if» имеет одну строку, НИКОГДА НЕ ИСПОЛЬЗУЙТЕ СКРЕПКИ, ИСПОЛЬЗУЙТЕ ОДИН УКАЗАТЕЛЬ

Я предпочитаю вторую ( EndsWith ) версию. Это достаточно ясно, чтобы понять даже мой менеджер!

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

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

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

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

1) Получите доступ к символу в позиции, которая на единицу меньше длины, и проверьте, соответствует ли он символу 'r'

2) Проверьте, заканчивается ли он символом string "r"

Я думаю, это проясняет, какой ответ более удобен в обслуживании.

Я думаю, что правильным ответом будет тот, который на самом деле правильный. EndsWith правильно возвращает false для ввода пустой строки, тогда как другой тест выдаст исключение при попытке индексирования с -1.

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

Вот отрывок из моей статьи:

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

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

Помните, что в классическом C единственная разница между «строкой» и массивом символов состоит в том, что завершающий нулевой символ '\ 0', поэтому у нас чтобы более активно относиться к ним и следить за тем, чтобы мы не сбежали с конца массива. Итак, первый блок кода основывает свой мыслительный процесс на концепции массива символов.

Второй блок кода основывает мыслительный процесс на том, как вы обрабатываете строку более абстрактно и с меньшим вниманием к ее скрытой реализации.

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

Некоторые из них могут суммировать вклад других на этом этапе, но, более точно, вы играете в «Бинго ()»; или вы "играете в игру с двумерным массивом случайных целых чисел и т. д."? "

Надеюсь, это поможет.

Джим