Следует ли указывать единицы измерения в именах атрибутов?

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

Например, если интервалы ВСЕГДА указаны в минутах и ​​т. Д.

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

Тем не менее, я склонен к вам в этом вопросе. Ясность важнее всего, в том числе и этого. Я бы предпочел посмотреть DurationMinutes, чем Duration, и угадал бы, что такое UOM.

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

Например, в случае с классом высокопроизводительного таймера, который мы используем, мне постоянно приходится проверять, возвращает ли метод GetElapsed () секунды, миллисекунды или что-то еще. Если бы он был вызван GetElapsedMilliseconds (), это избавило бы от путаницы.

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

В F# есть интересный поворот, позволяющий указывать единицы измерения в системе типов. См. Этот Сообщение блога и еще один вопрос о переполнении стека, посвященный Единицы измерения уникальны для F#?

Where the unit of measurement isn't immediately apparent, I think you should go a step further and include the unit of measurement in the name. Length_mm, for example, should help remind developers that they'd better convert the length to mm if the user just entered it in inches.

Вы можете пойти еще дальше (в своем коде, а не в базе данных) и иметь тип Length, который заботится об единицах измерения и возможных преобразованиях. Это подход модели «Количество» в книге Мартина Фаулера «Модели анализа».

НЕТ, название атрибута не зависит от его единицы измерения.

Если вы вызываете переменную length_mm, вы привязаны к mm.

что, если вы используете 32-битное int для хранения length_mm, в конечном итоге длина в мм может стать больше, чем 62000, или независимо от того, какой предел установлен для 32-битных int. Вы не можете переключиться на m, потому что вы связали переменную длины с length_mm.

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

Не указывайте единицы измерения (или тип столбца) в именах столбцов базы данных.

Многие базы данных имеют возможность каким-либо образом документировать / комментировать столбцы (в SQL Server это sp_addextendedproperty), я бы предположил, что это более подходящее место.

Вот почему Марсианский климатический орбитальный аппарат врезался в поверхность на скорости 350 метров / сек, когда планировалось выдержать только 350 футов / сек (или что-то в этом роде).

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

Соглашение об именовании всех моих столбцов в формате:

{name}_in_{unit}

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

length_in_m
speed_in_ms-1
color_in_nm

было несколько исключений, которые я обработал либо с _at_time, либо с number_of_:

start_at_time updated_at_time number_of_rotations

Идеальный подход - по возможности использовать тип, не допускающий двусмысленности в отношении измерения. Например, в .NET вместо int periodInSeconds лучше использовать TimeSpan period.

В языке F# единицы измерения фактически являются частью системы типов, поэтому вы можете объявлять типы в таких единицах, как 10<m/s> и 5<s>, и даже выполнять с ними вычисления, чтобы что-то вроде 10<m/s> * 5<s> приводило к 50<m>. См. Здесь для получения дополнительной информации.

Поэтому я бы сказал, что если возможно, используйте тип, который передает ваше намерение, но если это невозможно, вам, вероятно, следует закодировать измерение в имени. Это лучше и очевиднее, чем комментарий.

Должен сказать, я ненавижу «описательные» имена переменных, превращающиеся в «невероятно подробные» имена переменных.

Я предпочитаю использовать в коротких функциях только имена единиц измерения. Например.

function velocity(m, s) {
   return m/s;
}

Вам не нужно говорить «length_m», потому что в этом контексте очевидно, что в метрах можно измерить только длину.

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

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

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

Вам определенно нужны единицы измерения где-то. Я не знаю, подходят ли имена столбцов или схема лучше. Спросите своего администратора базы данных

• Где хранится информация об единицах измерения?
• Как я могу получить доступ к объектам программно?

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

P.S. Мне очень нравится поддержка единиц измерения, которую они поместили в F#.

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

Да. Вам следует.

Ключевым моментом, как указал @ [Charles Bretana], является удобочитаемость и то, что другие пользователи вашей таблицы или разработчики, следующие за вами, знают, что вы используете.

Я бы обязательно включил единицы / измерения в название поля - в моем бизнесе вы не можете догадаться, что вы найдете из контекста или имени: поле под названием MarketValue - это миллионы, тысячи или единицы? Доллары США, евро, фунты стерлингов, ВАЛЮТА $? Это значение в процентах, в соотношении? Абсолютное или относительное? Ежедневно, ежемесячно, календарный год, финансовый год? Эта отметка времени, какой это часовой пояс?

Ваша первая, последняя и единственная задача при предоставлении данных - убедиться, что они не используются неправильно, потому что потребитель не смог узнать о них достаточно. Как разработчики, добавление «Meter», «USD», «GMT», «PerCent» или чего-то еще в имя поля не является ни малейшим запахом.

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

Для времени Python рассмотрите возможность использования объектов из пакета datetime. Это позволит зафиксировать имплицитность единицы измерения с микросекундным разрешением. Тогда нет оснований для включения единицы в имя переменной.

Если вместо этого вы должны использовать int или float, настоятельно рекомендуется добавить к имени переменной суффикс аббревиатуры имени устройства. Например, вместо имени переменной diff используйте diff_secs для секунд, diff_ms для миллисекунд, diff_µs для микросекунд или diff_ns для наносекунд.