Хороший и плохой код

хе
был сервер, который выдавал FALSE при провале авторизации и список адресов при успешной. Замучился с клиентом - трудновато читать список после ожидания FALSE. Решение: следом за FALSE посылаем TRUE. Клиент один фиг ждет FALSE чтоб сообщить о провале, а тут он получает TRUE, не понимает что это и переходит к чтению списка адресов. И нефиг лезть куда-то в алгоритмы

 

device
что такое хороший и плохой код спорят уже десятки лет и все никак не придут к соглашению, особенно, если предполагается совместная работа над кодом людьми с разным уровнем подготовки и разными религиями, в смысле парадигмами. кто-то тяготеет к использованию шаблонов, кто-то закрывает все методы класса, кто-то вообще дает прямой доступ к его внутренней кухне. и ведь каждый может аргументировать свою позицию. ну вот допустим, у нас есть объект типа "файл" и начинающий программист реализовал базовый функционал: открыть/закрыть файл, прочесть/записать, переместить указатель/возвратить текущую позицию. и ему кажется, что это достаточно для решения 100% задач, но он заблуждается, потому как кому-то может приспичить проверить: а не открыт ли данный файл? или вообще получить список открытых файлов. или по дескриптору открытого файла определить его имя. вот и приходится вторгаться во внутреннею кухню класса, используя разные "хаки" для доступа к его внутренним структурам, которые могут в любой момент измениться, но... это и есть расплата за возможность закрытия методов в ООП. в чистом Си все проще. там все торчит кишками наружу и получить тот же список открытых файлов можно и без хаков

кстати, комменты лучше писать на eng. проверенно на собственном опыте. как только тебе придется показать свой код кому-то еще и этот "кто-то" не шарит в rus, ты поимеешь конкретный гемор.

 

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

 

halyavin

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

 

GOF прочитал - вопросов все больше.

Вот я создал класс RightsDetector. Ему определил 3 состояния
ST_FULL;
ST_READ_ONLY;
ST_NONE;

и 2 метода: changeState, чтоб сменить состояние и getState, чтоб получить состояние.

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

Будет ли хорошим тоном, добавить к нему еще методы для установки/удаления прав или следует писать другой класс?

 

А еще лучше использовать все шесть рабочих языков ООН (eng, esp, rus, chin, fr, arab) - для полной политкорректности