Цитата(Kabdim @ Apr 4 2017, 11:56)
Кмк эта возможность писать слитно слишком слишком демонизируется. Этот вариант написания один из возможных, т.е. программист может выбрать его там где он будет уместен. Например isalpha, в качестве локальной переменной - почему бы и нет.
А потому что в английском язые нет слова "isalpha", а есть два слова Is или Alpha, поэтому логичнее изменить на "isAlpha", is_alpha или IsAlpha.
Английский Язык Предусматривает Написание Каждого Слова Предложения Заглавными Буквами, а русский - нет.
Поэтому логично предположить, что и все правила английского языка распространяются на код, на котором он написан.
Цитата
А в тех местах где это не уместно предлагаются подчеркивания.
Я раньше применял такое правил, но отказался - глаз спотыкается об эти подчеркивания, а пользы я не нашел.
К тому же как только переменная меняет области видимости (локальная - глобальная - поле класса), ее ВЕЗДЕ приходится переименовывать.
Какой в этом смысл? Зачем в название переменной вносить область ее видимости?
Мне кажется более логичным создать ее экземпляр непосредственно перед тем местом, где она используется (в стеке).
В С++ такое возмоно, но не в С.
Например:
Код
for (int index = 0; ....)
{
...
}
Если в коде опять будет цикл, можно создать переменную с точно таким же именем, но это будет совсем ДРУГАЯ переменная,
что заставляет узко локализовать область использования временных (локальных) переменных, а не раскидывать их по всему коду функции,
особенно, если она вся не влазит на экран.
Хотя я стараюсь минимизировать число локальных переменных и главное - дробить огромные функции.
Цитата(Aaron @ Apr 4 2017, 12:30)
очевидно же - у класса есть конструкторы/деструкторы и private/protected области видимости =)
В структуре все поля, если не указано public/private/protected, являются по-умолчанию public, а в классе - private.
Это - единственное отличие между структурой и классом. В остальном они отличаются лишь названием
Цитата(jcxz @ Apr 4 2017, 12:23)
Это как это?
Структура у меня используется лишь как структурированное хранилище данных (часто упакованы с соотв. атрибутами типа packed), т.е. ТОЛЬКО ПОЛЯ,
а класс - уже что-умеет делать сам, т.е. у его есть еще и МЕТОДЫ.
Я делю их между собой именно так, хотя прекрасно знаю, чем они отличаются на самом деле (см. выше).
Структур (struct) в коде у меня очень мало и почти все они имеют крайне локализованный характер, т. е. обладают очень узкой областью видимости. Насколько это возможно.
На самом деле, я немного слукавил, приведя в пример возможность структуры стать классом )) Обычно, это происходит не так явно - просто, резко сужается область видимости структуры и она попадает лишь внутрь соотв. класса.
Небольшое дополнение насчет макросов и замен "магических" чисел.
Поскольку в коде у меня нигде нет глобальных объектов, ни одного,
то это создает некоторые сложности с отказом от моего правила - макросов и замен "магических" чисел - БОЛЬШИМИ_БУКВАМИ_С_ПОДЧЕРКИВАЕНИЕМ.
Т. е. в моем случае такие "дефайны" имеют исключительно глобальный смысл и каждый объектный модуль при желании может их использовать.
Таким образом получается, что я как бы намекаю (сам себе, разумеется), что речь идет не об объектах, а лишь заменах (дефайнах), которые при компиляции (после препроцессора) станую обычными числами и выражениями.
Поэтому сильно сомневаюсь, что макросы и замены буду именовать иначе, чем так, как сейчас ))
. Особенно убивает, когда комментарий провильный, а то, что в исходнике с ошибкой. 
