Как сделать имена переменных (полей) более читаемыми? Здравствуйте, во время разработки постоянно приходится создавать переменные и поля, в именах которых приходится указывать наследование.
Например, есть объект - contact_book;
у него есть дочерние объекты - contacts
(contact_book => contacts).
Т. е. выходит что-то на подобии такого (в стиле under score): contact_book_contacts
Или такого (в стиле camel case): contactBookContacts
Подобные имена очень сложно считывать, оссобенно если указывать какие либо дополнительные прилагательные и наследование. Например: contact_book_deleted_contact (content book => deleted contact) или contact_book_deleted_contact_first_field (contact book => deleted contact => first field).
Приходило в голову, что можно совместить lower case и camel case, на подобии: contactBook_deletedContact_firstField,
или в БЭМ-like стиле: contact_book__deleted_contact__first_field.
Но всё это уже какой-то изврат.
Собственно сами вопросы:
Как вы реализуете это у себя в коде или БД?
Существуют ли какие-нибудь подходящие методологии наименования?
Как сделать имена переменных (полей) более читаемыми? Здравствуйте, во время разработки постоянно приходится создавать переменные и поля, в именах которых приходится указывать наследование.
Например, есть объект - contact_book;
у него есть дочерние объекты - contacts
(contact_book => contacts).
Т. е. выходит что-то на подобии такого (в стиле under score): contact_book_contacts
Или такого (в стиле camel case): contactBookContacts
Подобные имена очень сложно считывать, оссобенно если указывать какие либо дополнительные прилагательные и наследование. Например: contact_book_deleted_contact (content book => deleted contact) или contact_book_deleted_contact_first_field (contact book => deleted contact => first field).
Приходило в голову, что можно совместить lower case и camel case, на подобии: contactBook_deletedContact_firstField,
или в БЭМ-like стиле: contact_book__deleted_contact__first_field.
Но всё это уже какой-то изврат.
Собственно сами вопросы:
Как вы реализуете это у себя в коде или БД?
Существуют ли какие-нибудь подходящие методологии наименования?
Например, есть объект - contact_book;
у него есть дочерние объекты - contacts
(contact_book => contacts).
Т. е. выходит что-то на подобии такого (в стиле under score): contact_book_contacts
Или такого (в стиле camel case): contactBookContacts
Подобные имена очень сложно считывать, оссобенно если указывать какие либо дополнительные прилагательные и наследование. Например: contact_book_deleted_contact (content book => deleted contact) или contact_book_deleted_contact_first_field (contact book => deleted contact => first field).
Приходило в голову, что можно совместить lower case и camel case, на подобии: contactBook_deletedContact_firstField,
или в БЭМ-like стиле: contact_book__deleted_contact__first_field.
Но всё это уже какой-то изврат.
Собственно сами вопросы:
Как вы реализуете это у себя в коде или БД?
Существуют ли какие-нибудь подходящие методологии наименования?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Для улучшения читаемости имен переменных и полей в коде, можно использовать следующие методики:
Использование осмысленных имен: названия переменных должны отражать их назначение и контекст использования.Использование camelCase или snake_case: придерживайтесь одного стиля именования и придерживайтесь его по всему проекту.Избегайте слишком длинных и сложных имен: старайтесь использовать короткие и точные названия, которые легко читаются.Используйте аббревиатуры и сокращения, если они широко распространены и понятны в контексте проекта.Группируйте переменные схожего типа в одной области именования, чтобы уменьшить вероятность конфликтов и улучшить читаемость кода.При необходимости указания наследования или иерархии объектов, используйте подходящие префиксы или суффиксы, но не утяжеляйте имена излишне.Каждый проект и команда разработчиков могут иметь свои правила и стандарты именования переменных, поэтому важно согласовывать эти аспекты внутри своей группы. В целом, главное - следовать единым стандартам и стараться делать имена переменных максимально понятными и легко читаемыми.