Кого это волнует… главное, чтобы результат был в порядке?
https://stackoverflow.com/questions/484676
-
20-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я немного ошеломлен множеством реакций на вопросы, которые указывают на то, что разработчики больше заботятся о результирующих скомпилированных байтах, чем о значении своего кода.Я склонен придираться к приращению постфикса / префикса, так же как я склонен придираться к использованию логического значения для перечисляемого типа с двумя значениями и к правильному именованию функций, и...
Так что этот вопрос скорее является переосмысленным опросом:когда кому-то позволено пренебрегать семантикой того, что он пишет?Где проходит линия границы?
- оператор++ (постфиксный/префиксный)
- string.empty() противстрока == ""
- vector.empty() противвектор.размер() == 0
- перечислять {вкл., выкл.} противлогическое значение вкл.=true;выкл.= ложь
- ...
Назовите это.
Редактировать -
Я не имел в виду задавать вопрос о необходимости (микро)-оптимизации.Скорее, я хочу услышать мнение о том, насколько хорошо вы должны быть осознающий о том, что вы пишете, и о заявлениях типа "но это все равно компилируется в dword, так почему я должен делать это перечислением?" (это крайний случай ...).
Решение
Я написал много из кодекса в моей карьере.Конечно, не так много, как у многих людей здесь, но, тем не менее, много кода.За это время я усвоил одну вещь, которая снова и снова подтверждалась:Когда ты становишься неаккуратным, когда ты игнорируешь детали, вкрадываются дефекты.
Устранение дефектов требует времени и денег.Вы можете либо потратить время на написание кода чисто и разборчиво с самого начала, когда это обходится дешево, либо потратить много времени и денег позже на устранение дефекта в коде, который вы, вероятно, не очень хорошо помните, потому что вы собирали его в спешке или потому что он не соответствует стандарту кодирования.Конечным результатом является, вы напрасно тратите время и деньги. Кроме того, вы напрасно тратите время и деньги, которые вам не нужно было тратить с самого начала, потому что этого можно было бы избежать с помощью небольших первоначальных инвестиций.
Я никогда не жалел о том, что был скрупулезен в том, как я пишу код.Это никогда не возвращалось, чтобы преследовать меня.Неряшливость всегда возвращалась, чтобы преследовать меня.
Другие советы
Определите "ок".Нормально ли, если это работает в начальную дату поставки, но каждый раз, когда вам нужно внести изменения, требуется дополнительные три недели, чтобы разобраться со старым кодом?
Вот твой ответ:до тех пор, пока вы можете понимать код и это не повредит вашей способности поддерживать его.
Когда вы начинаете беспокоиться об эзотерических вещах, которые никак не влияют на конечный результат, я думаю, это заходит слишком далеко.Дискуссии типа того, использовать ли троичный оператор или писать явные инструкции if, хороши в те дни, когда вам нечего делать, кроме как откинуться на спинку стула, задрать ноги, потягивать пиво / вино / содовую и обсуждать "важные вопросы" :)
Но создавать перечисление для boolean просто неправильно.
Зависит от вашей функции затрат
Вот пара измерений, о которых люди любят спорить и часто объединяют их.На самом деле, ответ в том, что это зависит.Что вы действительно цените?
- Количество символов
- Количество созданных операций
- Время выполнения
- Переносимость
- Ремонтопригодность
- Ясность
- Сообразительность
- Стабильность (без ошибок?)
- Расширяемость
Я всегда стремлюсь в первую очередь к вещам более высокого порядка, таким как ясность.Потеря ясности оплачивается человеческими циклами, которых всегда не хватает.Люди редко заботятся о необработанном времени на часах, а люди, которые говорят, что заботятся, почти всегда оптимизируют преждевременно.
Если это вам хоть как-то поможет, мне нравится думать, что мы добиваемся прогресса, продвигаясь вверх по стеку, больше заботясь о семантике и выполнении работы, а не будучи рабами битов и чисел.Однако это не повод забывать основы и помнить, как реализуются определенные семантические биты.Вы же не хотите, чтобы вас застукали со спущенными штанами во время тех редких возможностей, когда скорость начинает иметь значение, а условности вылетают в окно.
"когда кому-то позволено пренебрегать семантикой того, что он пишет?Где проходит линия границы?"
Я думаю, что разумный вопрос заключается в:"когда следует кто-то пренебрегает семантикой того, что он пишет?"
Поскольку я рассматриваю программирование как человеческую деятельность, я бы сказал, что единственный раз, когда следует игнорировать семантику утверждения - это когда сама система вынуждает вас - когда какое - то непонятное утверждение является Только способ что-то сделать.Такие заявления хорошо документировать.
Граница - это когда вы имеете дело с кодом типа "запись-один раз, чтение-никогда".Только тогда в конечном счете не имеет значения, что вы делаете (в данном случае), потому что вы никогда не будете использовать это снова.К сожалению, это не учитывает косвенную обратную связь от практики, которую вы предпочли бы не повторять.
Пограничная линия - это побочные эффекты.
Если инкапсулированная функция делает все, что вы хотите, с 0 неожиданными побочными эффектами, И код читаем, это все, что имеет значение.Если вы предсказуемы для внешнего пользователя и любая "причудливая" функциональность поддерживается внутри компании, это все, что имеет значение.
Это немного изменится, если вы добавите оптимизацию, но поскольку вы никогда не должны проводить преждевременную оптимизацию, на этом все заканчивается.
Микрооптимизация бессмысленна в 99% случаев.Например, если ваш компилятор в любом случае подключает все "" к одному экземпляру, вы никоим образом не повышаете производительность, используя String.Пусто.Отсутствие какого-либо измеримого эффекта, как правило, лучшее, на что вы можете надеяться, я также видел, как "оптимизации" снижают производительность из-за того, что компилятор выполняет лучшую работу, а оптимизация мешает этому.
Большая часть кода не нуждается в оптимизации.Определить, где это должно произойти, можно только с помощью диагностики после запуска кода, и даже тогда большую часть времени это делается с помощью алгоритмической оптимизации, а не микрооптимизации.
Я думаю, что в наши дни большинство людей согласны с тем, что при условии, что это работает правильно, удобочитаемость является наиболее важным фактором.Конечно, есть исключения - некоторые приложения должны запускаться как можно быстрее, а некоторые могут никогда может произойти сбой, но, вообще говоря, это удобочитаемость.
Наблюдая за примерами, которые вы предоставили -- Следующее:
operator++ (постфиксный/префиксный)
string.empty() против. string == ""
Не кажутся хорошими примерами, поскольку они сравнивают операции, которые отличаются в functionality.Следовательно, один лучший не не обращайте внимания на их семантические различия.
В отличие от этого, следующие примеры:
vector.empty() против. vector.size() == 0
enumвозводить { on, off} против boolean on=true; off=false
Являются совершенно разумными.
vector.empty() предпочтительнее, если контекст его использования заключается только в том, чтобы определить, является ли вектор пустым.Рискуя показаться снисходительным (что я и делаю не намереваюсь быть):это сводится к здравому смыслу.Зачем спрашивать размер вектора, если вы только хотите знать, пуст ли он?Это все равно что спросить кого-то, сколько у него денег в кошельке, когда вы просто хотите узнать, достаточно ли у него наличных, чтобы купить кока-колу.
Что касается enumвозводить { on, off} против boolean on=true; off=false, задайте себе этот вопрос:насколько вероятно, что вы можете добавить другое значение к перечислению в будущем?Кажется разумным, что кто-то мог бы захотеть enumвозводить{on, off, indeterminate}` (или какой-то вариант), так что ответ может быть утвердительным.В противном случае было бы достаточно простого логического значения.
Это подводит меня к сути вашего вопроса:что, по-видимому, означает, существует ли какой-то детерминированный / алгоритмический подход к принятию того или иного решения по таким вопросам, как эти, или их актуальности?Мой ответ таков: до того дня , когда Машины Тьюринга способны передать Тест Тьюринга, Я бы сказал, нет.Это причина, по которой люди должны разрабатывать программное обеспечение.
