Какой из двух кодов будет более читабельным и удобным для использования?

Question

[have_a_nice_day13]

1 вариант:

class draw_t
{
public:
	void information(...);

	void center_text(...);
	void colored_text(...);
	void action_text(...);

	void animated_bar(...);
	void animated_window(...);
};

вариант 2:

class draw_t
{
public:
	class other_t
	{
		void information(...);
	};
	class text_t
	{
		void center(...);
		void colored(...);
		void action(...);
	};

	class animted_t
	{
		void bar(...);
		void window(...);
	};

	other_t other;
	text_t text;
	animated_t animted;
};

Comments

[edward_freedom]

мне больше второй вариант. А что значит приставка _t?

[have_a_nice_day13]

edward_freedom, к суффиксу _t у меня любовь, мне так больше нравится код :)

[Василий Банников]

have_a_nice_day13, Может лучше будет просто типы называть с большой буквы?

[edward_freedom]

have_a_nice_day13, а что он значит? Я не спец в плюсах, но на сколько я знаю, суффиксы ставят в начале

g_nWheels : member of a global namespace, integer
m_nWheels : member of a structure/class, integer
m_wheels, _wheels : member of a structure/class
s_wheels : static member of a class
c_wheels : static member of a function

Нотация
https://en.wikipedia.org/wiki/Hungarian_notation

[have_a_nice_day13]

edward_freedom, вообще _t означает typedef, но как видно, я использую его не по назначению, видел в некоторых работах как ребят с этих форумов, так и с других что они так же указывает class name_t , мне это понравилось.

[edward_freedom]

have_a_nice_day13, я вообще не понимаю, зачем это все помечать. В c# ничего не надо и все отлично читается, классы функции с большой буквы, приватные методы в классе через _

[Adamos]

edward_freedom, да и в Крестах, и в Джаве, и даже в Пыхе давно уже принято называть классы с большой буквы. А эти суффиксы - сишное наследство, архаизм.

[Евгений Шатунов]

edward_freedom, про Венгерскую нотацию ты написал верно. Она используется для передачи контекста и, во многом, является пережитком прошлого и просто избыточна.
Суффикс _t является частью соглашения об именовании.

А вот have_a_nice_day13 в своих словах не прав. К typedef суффикс отношения не имеет.

[have_a_nice_day13]

Евгений Шатунов, владел только той информацией, что - _t = typedef

[have_a_nice_day13]

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

[Adamos]

have_a_nice_day13, Макконнелл в "Совершенном коде" весьма развернуто и доходчиво ответил на подобные и смежные вопросы уже довольно много лет назад.

[Евгений Шатунов]

have_a_nice_day13,

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

Я так понимаю, это вопросительное предложение?

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

владел только той информацией, что - _t = typedef

Ошибаться для человека - нормально. Не ошибается только тот, кто ничего не делает.
Теперь у тебя есть более точные знания, которыми ты можешь делиться дальше.

[have_a_nice_day13]

Евгений Шатунов, замечательно, очень рад познавать новое, верно подметил про ошибки людей, респект.
ладно, перейдем к самому вопросу - начеркал немного кодика, жду критики именно насчёт оформления, читабельности и удобности. :)

namespace client
{
	struct data_t
	{
		struct authorization_t
		{
			const char* login = nullptr, *password = nullptr;
			size_t login_sz = 64, password_sz = 32;

		} authorization;

		const char* mac = nullptr, *proc_id = nullptr, *mbios = nullptr;

		struct logged_in
		{
			struct subscribe_t
			{
				const char* product = nullptr;
				int id;
				const char* status = nullptr, *expired = nullptr;
			};

			std::vector<subscribe_t> subscribe;

		} authorized;
	} data;

	class connection_t
	{
	public:
		enum class status_t
		{
			idle,
			connected,
			logging_in,
			logged_in,
		};

		void connect();
		void send_data();
		void receive_data();
		void shutdown();
	};

	class request_t
	{
	public:
		enum class auth_responses_t
		{
			unknown_user,
		};

		auth_responses_t authorization();
	};

	class utilities_t
	{
	public:
		const char* get_mac();
		const char* get_proc_id();
		const char* get_mbios();
	};

	connection_t connection;
	request_t request;
	utilities_t utilities;
};

p.s в моем проекте практически все классы объявлены глобально. потому что вся программа в бесконечном цикле. при нужде я могу объявить класс в нужном мне блоке.

[Евгений Шатунов]

have_a_nice_day13, кода мало, тебе нужно еще объяснить все написанное словами. В чем конкретно смысл существования каждого типа, каждого поля, каждой функции. Если ты не можешь связно сформулировать смысл существования кода, просто сотри его. Код, который ты не можешь объяснить, существовать не должен.

Без этого объяснения я могу посмотреть на этот код только с т.з. синтаксиса и общего восприятия.
Пространство имен - это неплохо. Зачем оно создано? Что оно содержит внутри себя? Почему оно называется абсолютно безликим словом client, которое ничего не выражает?
struct data_t - абсолютно никак не объясняет смысл своего существования. Слово Data не выражает ничего, оно просто говорит что внутри какой-то бессвязный белый шум из байтиков. Почему для определения типа выбрано слово struct? Почему не class?
struct authorization_t - словом Authorization обозначают данные уже авторизовавшегося пользователя, которому уже присвоен идентификатор сессии. У тебя в этой структуре записаны поля, которые другими людьми оформляются в термин Authentication. Разница между этими терминами даже близко не позволяет один с другим сравнивать.
const char* login = nullptr, *password = nullptr; - через запятую никогда не пишем. Каждое поле должно быть легко читаемо на своей отдельной строке. А вот таким определением полей через запятую ты ничего не добиваешься, кроме как только усложнения чтения кода. Правило 0 при написании кода - не создавать проблем для его чтения.
const char* login - константностью данных управлять нужно не так. Именно объекты типа struct authorization_t должны наделяться свойством константности там, где это требуется. Состояние же этих объектов константным делать просто незачем.
const char* login ... size_t login_sz - при инициализации по умолчанию поле } authorization; имеет неконсистентное и алогичное состояние. Более того, такой набор полей нельзя отнести к коду на языке C++. Эта структура написана на C. Весь набор полей нужно изменить на два поля с типом std::string если ты хочешь писать на C++.
} authorization; - от кого ты прячешь этот код? Определение поля должно быть легко читаемым. Сейчас оно абсолютно нечитаемое. Чтобы найти это поле глазами, требуется много непозволительных для этого занятия усилий. И, опять же, это не Authorization, а Authentication. С моей т.з. такого поля в этом месте существовать вообще не должно.

const char* mac = nullptr, *proc_id = nullptr, *mbios = nullptr;

- все так же, через запятую поля никогда не определяем. Более того, тут уже пошли очень странные нечитаемые и непонятные имена. mbios - что это, акроним или именование в стиле СовКомПоМорДе (Советский Комитет По Морским Делам)? Такие имена невозможно прочитать, они не отражают смысла своего существования. Почему в authorization_t для полей с типом const char* есть семантическая пара size_t, а тут - нет? Все эти поля нужно заменить на std::string.

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

в моем проекте практически все классы объявлены глобально. потому что вся программа в бесконечном цикле

Наличие статически определенных объектов оправдано может быть только требованиями соблюдения стандарта MISRA при разработке встраиваемых систем. В ином случае все статически определенные объекты должны иметь доказательство своей необходимости. Наличие бесконечного цикла не обосновывает необходимость статического размещения каких-либо данных.

[have_a_nice_day13]

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

[Евгений Шатунов]

have_a_nice_day13, все просто. Тебя не поймут другие люди. При чем, не поймут они тебя именно в плохом смысле, они будут на тебя очень злы. Это потому что ты таким кодом заставляешь их напрягаться и вчитываться для того чтобы найти интересующую их переменную.
Наверное ты невнимательно прочитал в первый раз, я повторю еще раз. Правило 0 при написании кода - не создавать проблем для его чтения.

Найди в этом коде переменную impression.

float intension, empation, insignion, imposion;
int impresumption, impetition, inversion, illustration;
bool illusion, impretendion, imperception;

На это занятие ты потратишь непозволительно много времени.
Поиск термина при чтении такого кода - это трехмерный поиск. Одно измерение - это столбцы типов, второе - это строки слов через запятую, третье измерение - это сами слова посимвольно, каждое из которых тебе надо вычитать глазами.
Поиск термина при чтении объявлений в столбик - это двухмерный поиск. Искать в трехмерном пространстве значительно сложнее по сравнению с пространством двухмерным. А когда в такой трехмерный код добавляется инициализация по месту определения, читать его становится только сложнее.

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

[have_a_nice_day13]

Евгений Шатунов, хорошо, насчёт в строчку я тебя понял, больше так не буду делать, спасибо большое.
а как ты относишься к такому варианту?

static bool notification_user_invalid = false,
	notification_mismatch_username = false,
	notification_mismatch_passsword = false;

[Евгений Шатунов]

have_a_nice_day13, это тоже сбивает с толку. Вот где тип? Почему когда я нашел место переменной по ее имени, мне снова надо искать ее тип? У меня сейчас в голове контекст своей задачи на изменение этого кода, а все подобные игры в прятки заставляют меня переключаться со своего контекста.
Тут я позволяю себе эмоциональный окрас только чтобы передать тебе примерную атмосферу, в которой будет рассматриваться такой код.

Выражение в C++ всегда завершается символом ;, который находится в конце строки. Люди ждут выражений не более чем в одну строчку. Когда в конце строки находится не ;, код снова начинает сбивать читателя с толку. В самом крайнем случае допускается разбивка арифметических выражений на несколько строк. Да и то, на ревью такой код с вероятностью 80% потребуют переформулировать в пояснительные константы. Больших арифметических выражений в коде тоже быть не должно.

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

Тебе определенно стоит ознакомиться с рекомендациями по стилю кода, например: [1], [2], [3], [4], [5].
Еще тебе обязательно стоит изучить книгу Д. Босуэлла "Читаемый код". Там описывается много способов упрощения жизни себе и другим людям.

[have_a_nice_day13]

Евгений Шатунов, искренне люблю твои ответы. спасибо тебе большое. займусь работой над этим!

Answer 1

[Василий Банников]

Второй вариант, имхо, лучше. Хотя я не уверен на счёт суффикса _t
Ещё мне кажется, что тут не стоит делать кучу вложенных классов.

Answer 2

[Adamos]

Если у вашего класса куча публичных вложенных классов - скорее всего, вы просто еще не дочитали до главы "Namespaces" учебника.

Comments

[have_a_nice_day13]

Adamos, ошибаетесь. работа с классами мне больше нравится.

[Adamos]

have_a_nice_day13, ну, вопрос-то не о фетишах, а о читабельности и удобстве.

[have_a_nice_day13]

Adamos, предложите свой вариант. так же практикую методику с namespace a { class b{ }; };

[Adamos]

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

[Василий Банников]

Adamos,

гнусно надругаться над принципами SOLID, прямо с первой буквы.

Не стоит слепо следовать SOLID. В некоторых случаях подобный корневой объект будет очень полезен, хотя всё равно не следует реализовывать всё в одном месте.

[Adamos]

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

[Василий Банников]

Adamos, не достаточно информации. Пока вижу, что в кучу свалено только объявление классов.

[Adamos]

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

Answer 3

[liquiddeath13]

Сам использую второй вариант в своём коде, но всё же не уверен, что это наилучшая практика
Надеюсь, что в этом треде кто-то предложит свой, третий вариант