С какой буквы желательно начинать имена интерфейсов

имя сетевого интерфейса

Помогите разобраться с проблемой. Как я заметил, у меня в сети на всех компьютерах с Ubuntu 12.04 всегда неправильно назначаются имена сетевых интерфейсов. Есть исключения, но в основном у интерфейсов неправильные имена. То есть, нумерация интерфейсов начинается не с нуля. Первый интерфейс может носить имя «eth2». Я проверял содержимое /etc/udev/rules.d/70-persistent-net.rules. В списке есть «лишние» сетевые интерфейсы. Один или два. Вообще, это ни на что не влияет, но привычнее, когда первая сетевая карта — eth0, а вторая eth1. Я просто меняю имя в вышеуказанном конфиге, но может как-нибудь можно отключить «лишние» сетевые интерфейсы?

Спасибо за все ответы.

redstar
19.06.14 11:39:32 MSK

Можешь вообще содержимое этого конфига удалить. Оно перегенерируется снова при загрузке ОС.

Можешь вместо eth написать что хочешь там.

DALDON ★★★★★
( 19.06.14 12:21:46 MSK )

Ну так удали лишние строки из udev rules, в чём проблема-то? 🙂

generator ★★★
( 19.06.14 16:36:45 MSK )
Ответ на: комментарий от DALDON 19.06.14 12:21:46 MSK

Да, я так пробовал. Но вот как бы отключить «лишние» интерфейсы. Гуглил «how to disable network interfaces udev». Но там только про то, как отключить интерфейсы в конфиге сети или как переименовать интерфейс в udev.

redstar
( 20.06.14 15:14:37 MSK ) автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.

Похожие темы

• Форум Замена сетевой (2016)
• Форум Смена имени сетевого интерфейса (2012)
• Форум Ubuntu 16.04: Изменение наименования сетевых интерфейсов (2016)
• Форум При загрузке не поднимается сетевой интерфейс eth0 (2016)
• Форум Убрать привязку по MAC-адресу (2012)

• Форум настройка udev (2007)
• Форум Настройка сети в ubuntu (2008)
• Форум Убрать лишние подключения (2012)
• Форум Последствия сбоя электропитания и RTL8169 (Debian 7) (2013)
• Форум Непонятное поведение сетевых интерфейсов (2011)

Руководство Google по стилю в C++. Часть 8

Все мы при написании кода пользуемся правилами оформления кода. Иногда изобретаются свои правила, в других случаях используются готовые стайлгайды. Хотя все C++ программисты читают на английском легче, чем на родном, приятнее иметь руководство на последнем.
Эта статья является переводом части руководства Google по стилю в C++ на русский язык.
Исходная статья (fork на github), обновляемый перевод.

Именование

Основные правила стиля кодирования приходятся на именование. Вид имени сразу же (без поиска объявления) говорит нам что это: тип, переменная, функция, константа, макрос и т.д. Правила именования могут быть произвольными, однако важна их согласованность, и правилам нужно следовать.

Общие принципы именования

• Используйте имена, который будут понятны даже людям из другой команды.
• Имя должно говорить о цели или применимости объекта.
• Не экономьте на длине имени, лучше более длинное и более понятное (даже новичкам) имя.
• Поменьше аббревиатур, особенно если они незнакомы вне проекта.
• Используйте только известные аббревиатуры (Википедия о них знает?).
• Не сокращайте слова.

class MyClass < public: int CountFooErrors(const std::vector& foos) < int n = 0; // Чёткий смысл для небольшой области видимости for (const auto& foo : foos) < . ++n; >return n; > void DoSomethingImportant() < std::string fqdn = . ; // Известная аббревиатура полного доменного имени >private: const int kMaxAllowedConnections = . ; // Чёткий смысл для контекста >; 

class MyClass < public: int CountFooErrors(const std::vector& foos) < int total_number_of_foo_errors = 0; // Слишком подробное имя для короткой функции for (int foo_index = 0; foo_index < foos.size(); ++foo_index) < // Лучше использовать `i` . ++total_number_of_foo_errors; >return total_number_of_foo_errors; > void DoSomethingImportant() < int cstmr_id = . ; // Сокращённое слово (удалены буквы) >private: const int kNum = . ; // Для целого класса очень нечёткое имя >; 

Отметим, что типовые имена также допустимы: i для итератора или счётчика, T для параметра шаблона.

В дальнейшем при описании правил «word» / «слово» это всё, что пишется на английском без пробелов, в том числе и аббревиатуры. В слове первая буква может быть заглавной (зависит от стиля: «camel case» или «Pascal case»), остальные буквы — строчные. Например, предпочтительно StartRpc(), нежелательно StartRPC().

Параметры шаблона также следуют правилам своих категорий: Имена типов, Имена переменных и т.д…

Имена файлов

Имена файлов должны быть записаны только строчными буквами, для разделения можно использовать подчёркивание (_) или дефис (—). Используйте тот разделитель, который используется в проекте. Если единого подхода нет — используйте «_».

Примеры подходящих имён:

• my_useful_class.cc
• my-useful-class.cc
• myusefulclass.cc
• myusefulclass_test.cc // _unittest and _regtest are deprecated.

Не используйте имена, уже существующие в /usr/include, такие как db.h.

Старайтесь давать файлам специфичные имена. Например, http_server_logs.h лучше чем logs.h. Когда файлы используются парами, лучше давать им одинаковые имена. Например, foo_bar.h и foo_bar.cc (и содержат класс FooBar).

Имена типов

Имена типов начинаются с прописной буквы, каждое новое слово также начинается с прописной буквы. Подчёркивания не используются: MyExcitingClass, MyExcitingEnum.

Имена всех типов — классов, структур, псевдонимов, перечислений, параметров шаблонов — именуются в одинаковом стиле. Имена типов начинаются с прописной буквы, каждое новое слово также начинается с прописной буквы. Подчёркивания не используются. Например:

// classes and structs class UrlTable < . class UrlTableTester < . struct UrlTableProperties < . // typedefs typedef hash_mapPropertiesMap; // using aliases using PropertiesMap = hash_map; // enums enum UrlTableErrors < . 

Имена переменных

Имена переменных (включая параметры функций) и членов данных пишутся строчными буквами с подчёркиванием между словами. Члены данных классов (не структур) дополняются подчёркиванием в конце имени. Например: a_local_variable, a_struct_data_member, a_class_data_member_.

Имена обычных переменных

std::string table_name; // OK - строчные буквы с подчёркиванием 

std::string tableName; // Плохо - смешанный стиль 

Члены данных класса

Члены данных классов, статические и нестатические, именуются как обычные переменные с добавлением подчёркивания в конце.

class TableInfo < . private: std::string table_name_; // OK - подчёркивание в конце static Pool* pool_; // OK. >; 

Члены данных структуры

Члены данных структуры, статические и нестатические, именуются как обычные переменные. К ним не добавляется символ подчёркивания в конце.

struct UrlTableProperties < std::string name; int num_entries; static Pool* pool; >; 

См. также Структуры vs Классы, где описано когда использовать структуры, когда классы.

Имена констант

Объекты объявляются как constexpr или const, чтобы значение не менялось в процессе выполнения. Имена констант начинаются с символа «k», далее идёт имя в смешанном стиле (прописные и строчные буквы). Подчёркивание может быть использовано в редких случаях когда прописные буквы не могут использоваться для разделения. Например:

const int kDaysInAWeek = 7; const int kAndroid8_0_0 = 24; // Android 8.0.0 

Все аналогичные константные объекты со статическим типом хранилища (т.е. статические или глобальные, подробнее тут: Storage Duration) именуются также. Это соглашение является необязательным для переменных в других типах хранилища (например, автоматические константные объекты).

Имена функций

Обычные функции именуются в смешанном стиле (прописные и строчные буквы); функции доступа к переменным (accessor и mutator) должны иметь стиль, похожий на целевую переменную.

Обычно имя функции начинается с прописной буквы и каждое слово в имени пишется с прописной буквы.

void AddTableEntry(); void DeleteUrl(); void OpenFileOrDie(); 

(Аналогичные правила применяются для констант в области класса или пространства имён (namespace) которые представляют собой часть API и должны выглядеть как функции (и то, что они не функции — некритично))

Accessor-ы и mutator-ы (функции get и set) могут именоваться наподобие соответствующих переменных. Они часто соответствуют реальным переменным-членам, однако это не обязательно. Например, int count() и void set_count(int count).

Именование пространства имён (namespace)

Пространство имён называется строчными буквами. Пространство имён верхнего уровня основывается на имени проекта. Избегайте коллизий ваших имён и других, хорошо известных, пространств имён.

Пространство имён верхнего уровня — это обычно название проекта или команды (которая делала код). Код должен располагаться в директории (или поддиректории) с именем, соответствующим пространству имён.

Не забывайте правило не использовать аббревиатуры — к пространствам имён это также применимо. Коду внутри вряд ли потребуется упоминание пространства имён, поэтому аббревиатуры — это лишнее.

Избегайте использовать для вложенных пространств имён известные названия. Коллизии между именами могут привести к сюрпризам при сборке. В частности, не создавайте вложенных пространств имён с именем std. Рекомендуются уникальные идентификаторы проекта (websearch::index, websearch::index_util) вместо небезопасных к коллизиям websearch::util.

Для internal / внутренних пространств имён коллизии могут возникать при добавлении другого кода (внутренние хелперы имеют свойство повторяться у разных команд). В этом случае хорошо помогает использование имени файла для именования пространства имён. (websearch::index::frobber_internal для использования в frobber.h)

Имена перечислений

Перечисления (как с ограничениями на область видимости (scoped), так и без (unscoped)) должны именоваться либо как константы, либо как макросы. Т.е.: либо kEnumName, либо ENUM_NAME.

Предпочтительно именовать отдельные значения в перечислителе как константы. Однако, допустимо именовать как макросы. Имя самого перечисления UrlTableErrors (и AlternateUrlTableErrors), это тип. Следовательно, используется смешанный стиль.

enum UrlTableErrors < kOk = 0, kErrorOutOfMemory, kErrorMalformedInput, >; enum AlternateUrlTableErrors < OK = 0, OUT_OF_MEMORY = 1, MALFORMED_INPUT = 2, >; 

Вплоть до января 2009 года стиль именования значений перечисления был как у макросов. Это создавало проблемы дублирования имён макросов и значений перечислений. Применение стиля констант решает проблему и в новом коде предпочтительно использовать стиль констант. Однако, старый код нет необходимости переписывать (пока нет проблем дублирования).

Имена макросов

Вы ведь не собираетесь определять макросы? На всякий случай (если собираетесь), они должны выглядеть так:
MY_MACRO_THAT_SCARES_SMALL_CHILDREN_AND_ADULTS_ALIKE.

Пожалуйста прочтите как определять макросы; Обычно, макросы не должны использоваться. Однако, если они вам абсолютно необходимы, именуйте их прописными буквами с символами подчёркивания.

#define ROUND(x) . #define PI_ROUNDED 3.0 

Исключения из правил именования

Если вам нужно именовать что-то, имеющее аналоги в существующем C или C++ коде, то следуйте используемому в коде стилю.

bigopen()
имя функции, образованное от open()

uint
определение, похожее на стандартные типы

bigpos
struct или class, образованный от pos

sparse_hash_map
STL-подобная сущность; следуйте стилю STL

LONGLONG_MAX
константа, такая же как INT_MAX

Прим.: ссылки могут вести на ещё не переведённые разделы руководства.

• C++
• styleguide
• перевод с английского

С какой буквы желательно начинать имена интерфейсов

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

Одним из принятых соглашений в программировании является использование заглавной буквы «I» в начале имени интерфейса. Такой подход делает код более понятным и удобным для других разработчиков. Важно помнить, что именно буква «I» обозначает, что это интерфейс, а не класс или структура.

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

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

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

Лучшие практики и советы

При выборе имени для интерфейса следует придерживаться нескольких рекомендаций и лучших практик:

1. Используйте понятные и описательные названия. Имя интерфейса должно отражать его функциональность и назначение. Используйте краткое, но детальное название, чтобы другие разработчики могли легко понять, что делает данный интерфейс.
2. Избегайте слишком длинных имен. Хотя имя интерфейса должно быть описательным, не стоит делать его слишком длинным. Длинные имена могут быть неудобными при использовании в коде и усложнять чтение и понимание.
3. Старайтесь использовать существительные. Имена, состоящие из существительных, лучше отражают сущность интерфейса и его назначение. Это поможет другим разработчикам легче понять его функцию и использование.
4. Используйте заглавные буквы для разделения слов. Для улучшения читабельности и понимания имени интерфейса рекомендуется использовать заглавные буквы для разделения слов. Например, вместо «usersettings» используйте «UserSettings».
5. Следуйте общепринятым конвенциям и стилю кодирования. Если в проекте уже установлены определенные правила и рекомендации по именованию интерфейсов, следуйте им. Это поможет создать единообразие в коде и упростит поддержку и дальнейшую разработку проекта.

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

Почему важен выбор первой буквы

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

Во-первых, выбор первой буквы может сигнализировать о назначении и намерении интерфейса. Например, если интерфейс начинается с буквы «I», это может указывать на то, что это интерфейс, описывающий некоторый контракт или соглашение. Буква «T» может указывать на то, что это интерфейс-шаблон или обобщенный тип. Такие соглашения помогают разработчикам быстрее понять назначение и использование интерфейса.

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

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

Таким образом, правильный выбор первой буквы имени интерфейса имеет не только эстетическое значение, но и влияет на понимание, автодополнение кода и общую поддерживаемость проекта.

Как выбрать первую букву

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

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

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

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

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

Примеры выбора первой буквы интерфейса:

Первая буква	Значение
I	интерфейс
A	абстрактный
M	модифицирующий
P	процедурный

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

Рекомендации по использованию заглавной буквы

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

1. Используйте заглавные буквы для начала каждого слова в имени интерфейса. Это делает его более читабельным и позволяет легче различать отдельные слова.
2. Избегайте использования слишком длинных имен, особенно в случаях, когда их нужно будет часто использовать или писать. Длинные имена могут быть трудны для запоминания и могут вызывать путаницу.
3. Стремитесь к ясности и однозначности в именах интерфейсов. Они должны быть интуитивно понятными и легко запоминающимися.
4. Используйте заглавные буквы для указания важности или особенности интерфейса. Например, если у вас есть два интерфейса, один из которых представляет основной функционал, а другой – дополнительные настройки, можно использовать заглавные буквы в имени основного интрефейса, чтобы выделить его.

Примеры использования заглавной буквы в именах интерфейсов:

Имя интерфейса	Объяснение
IShape	Стандартный интерфейс для определения контракта фигуры
IDataFetcher	Интерфейс для получения данных
IUserSettings	Интерфейс для работы с настройками пользователя

Заглавная буква в именах интерфейсов помогает в создании читаемого и понятного кода, а также упрощает его поддержку и развитие.

Как избежать ошибок в выборе первой буквы

Выбор первой буквы имени интерфейса — важный шаг при разработке программного обеспечения. Правильное обозначение первой буквы может облегчить понимание и использование интерфейса другим разработчикам.

Вот несколько советов, как выбрать правильную первую букву для имени интерфейса:

1. Введите имя, отражающее назначение интерфейса: Перед тем как выбрать первую букву, определитесь с функциональностью и назначением вашего интерфейса. Это поможет вам выбрать соответствующую первую букву.
2. Выберите первую букву, основываясь на принятых соглашениях в команде: Если вы работаете в команде, обратитесь к соглашениям и стилю кодирования, принятым в вашей команде. Следование общим соглашениям поможет вашему коду быть более понятным и однородным.
3. Избегайте использования непонятных или неинформативных первых букв: Не используйте первую букву, которая не отражает назначение вашего интерфейса. Например, если ваш интерфейс отвечает за управление базой данных, не используйте «D» для имени интерфейса. Используйте более информативные и ясные первые буквы.
4. Используйте префиксы для имен интерфейсов, когда это уместно: Если ваш проект имеет несколько интерфейсов, начинающихся с одной и той же буквы, вы можете использовать префиксы для их имен. Например, при создании интерфейсов взаимодействия с базой данных можно использовать префикс «I» для всех интерфейсов, связанных с базой данных.

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

Вопрос-ответ

Какую букву лучше использовать для начала имени интерфейса?

Для начала имени интерфейса лучше использовать заглавную букву I. Заглавная буква I является общепринятой практикой в сообществе разработчиков и помогает обозначить, что это именно интерфейс.

Можно ли использовать другую букву для начала имени интерфейса?

Теоретически, можно использовать и другую букву для начала имени интерфейса, но это не рекомендуется. Однако, в таком случае следует быть более осторожным, чтобы не запутаться в коде. Использование заглавной буквы I является хорошей практикой и способствует читаемости и пониманию кода.

Какие еще рекомендации можно дать по именованию интерфейсов?

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

Наименование интерфейсов в Java

В мире объектно-ориентированного программирования часто встречается соглашение об именовании, согласно которому имена интерфейсов начинаются с заглавной буквы «I». Это соглашение широко применяется во многих языках программирования вроде C# или TypeScript и помогает разработчикам быстро определить, является ли данный тип интерфейсом или классом.

Однако в Java это соглашение не применяется. Вместо префикса «I» перед именем интерфейса, в Java обычно используют суффикс «Impl» после имени класса, который реализует интерфейс.

Возьмем для примера интерфейс «Пользователь» и его реализацию. В большинстве языков мы бы назвали их IUser (интерфейс) и User (класс). Но в Java мы имеем два варианта: UserInterface (интерфейс) и User (класс) или User (интерфейс) и UserImpl (класс).

Возникает вопрос: почему Java выбрала иной подход к именованию интерфейсов? И, что более важно, стоит ли следовать общепринятому соглашению об именовании интерфейсов, особенно учитывая текущие тенденции в разработке фреймворков на Java?

Во-первых, стоит отметить, что в Java нет строгих правил об именовании интерфейсов. Выбор между использованием суффикса «Impl» или префикса «I» остается за разработчиком.

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

Например, использование суффикса «Impl» может быть полезным в случае, когда ожидается, что у интерфейса будет только одна реализация. Это также может быть удобно при использовании контейнеров Inversion of Control (IoC), которые часто используют динамические прокси.

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

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