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

Вот хочется найти грань между этими понятиями.
Видите ли, я привык писать очень развернуто. Вот щас прогу пишу, там получилось 300 строк с небольшим.
Я прекрасно понимаю, что это можно уложить в 90 строк и я знаю как это сделать. Спецы, скажите, а стоит ли?

Надо ли ужимать код? У меня просто как болезнь - писать суперподробно.

К примеру, в программе есть такое дело:
1. Читать команду, которую прислали по сети (telnet)
2. определить, есть ли эта команда в массиве команд (Command[][])
3. Определить, какое количество параметров ей требуется
4. В цикле FOR принять эти параметры по очереди
5. Выполнить команду
6. Выдать результат
7. Прикончить сокет по номеру

Эти семь простейших действий расписаны как "Война и Мир " Толстого. Надо ли бороться с таким кодом или нет?

 

device

Ну, если скорость выполнения и размеры проги не критичны или на это вообще внимания никто не обращает - можно и обойтись.
У нас в конторе, к примеру, хороший код отличает количество используемых переменных, скорость исполнения программы и ее размер. Чем меньше - тем лучше ))

 

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

 

steelfactor
Ну да, У нас есть например указатель на такую структуру как ЧитательПотока (StreamReader)

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

Я не думаю что быстродействие сильно упадет. Просто я боюсь, что когда код будут читать другие специалисты, то они скажут: "Что за дурак ЭТО написал? Можно же короче!", хотя результат работы проги от этого не меняется.

 

device
Быстродействие может и не упадет, но память излишне захламлять не стоит, я думаю. Если это управляемый код, типа C#, то автоматическая уборка "мусора" хорошо помогает, не надо думать об освобождении выделенной памяти.
Впрочем, не мне тебе это рассказывать ))

 

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

 

Ну я комментарии вообще серьезные никогда не пишу

Код (Text):

1. public void CALL_SERV_CREAT (PrintWriter writer, String ServiceName, String IP, String PORT, String rights){
2. /**
3.  * Тут все куда сложнее:)
4.  * Мы не можем допустить создание сервиса, пока не опросим его
5.  *  на предмет правильности
6.  * Короче, с ним надо сначала поговорить, а потом уже зарегистрировать
7.  **/
8. try{
9. Socket sock = new Socket(IP, new Integer(PORT).intValue());
10. PrintWriter pw = new PrintWriter (new OutputStreamWriter (sock.getOutputStream()),true);
11. BufferedReader br = new BufferedReader (new InputStreamReader (sock.getInputStream()));
12.  
13. /** ПРОВОДИМ СТАНДАРТНЫЕ ТЕСТЫ СЛУЖБЫ **/
14.  
15. if (!br.readLine().equals("SERVICE>>ROOT")){writer.println("ERR_UNKNOWN_SERVICE");writer.close();}
16.  
17. /** Обмениваемся приветствиями **/
18.  
19. pw.println ("R>>HELLO");
20.  
21. if (!br.readLine().equals("N>>HELLO")){writer.println("ERR_UNKNOWN_SERVICE_HELLO");writer.close();}
22.  
23. /** Сервис ответил правильно, и мы его регистрируем **/
24.  
25. NataDB ndb = new NataDB ("INSERT INTO services (service_name, address, port, rights) VALUES (\""+ServiceName+"\", \""+IP+"\","+PORT+" ,\""+rights+"\");");
26. ndb.execute();
27. writer.println("ACCEPT");
28. writer.close();
29.  
30. }catch(Exception e){
31.  
32. /** Ой, у нас проблемы с сетью  - Надо сказать об этом клиенту, а то он тупой, сам не догадается, помрет еще:)**/
33. writer.println ("ERR_NETWORK");
34. writer.close();
35.  
36. }
37. }

 

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

 

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

 

wsd
Я знаю. Я знаю к чему может привести игнор, но обработчики ошибок я прописываю в самом конце.
Этот вариант для отладки.
Мне нужно удостоверится, что метод работает, а уж потом запотиться о перехвате Exceptions.

Кстати, мне код прислали, вот не вру и не преувеличиваю, но видать тот кто это писал, сильно разочаровался в пользователе

Код (Text):

1. class UserIsStupidException....
2.  
3. а дальше:
4. class UserIsVeryStupidException extends UserIsStupidException...

то есть они объявили исключение "ЮзерДурак" и от него потомок "ЮзерПолныйДурак". Видать, достали юзеры...

 

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

 

wsd

Ну почему сразу так категорично.. Если человек хочет ловить RuntimeException + все checked exceptions, то в самый раз. На высшем уровне я часто даже Throwable ловлю.

 

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

 

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

 

Автор функции должен предусмотреть это:

void BlackBoxVoid (Object param) throws SomeException....

И этот самый SomeException мы и будем обрабатывать.
Если это исключение не обработать, считай что кода после объявления этой ф-ции у тебя вообще нет.

 

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

 

Вам проще в этом отношении.

А вот когда пишешь код на трех-четырех языках сразу (Java + CNI + JNI/CPP + ASM) тут просто крыша едет... не спеша, тихо шифером шурша...
Причем чередование JNI и CNI вызывает такие эмоции, что потом уже не хочется смотреть на этот мир глазами трезвого человека.
И чтобы все получалось и код был рабочий, приходится выявлять исключения и обрабатывать их, даже если автор того или иного BlackBox компонента не предвидел ошибку. Иногда спасает знание алгоритма, а иногда просто интуиция.
Хотя в данной ситуации мне проще чем вам в том отношении, что я могу просто посмотреть на исходных код компонента BlackBox, если он присутствует, и увидеть что там происходит. Но даже при наличии сорцов BlackBox, можно видеть вызовы из еще более черных коробочек, вскрыть содержимое которых порой вообще не возможно.

 

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

 

На си вообще IF делает все!

Там в нормальных либах функции возвращают либо -1 либо что-то иное.

Да и вообще я давно уже вышел за рамки ЯП.
На чем бы вы не писали, смысл не меняется. У меня 40% кода на C++ и 60 на Java
И сключения - это кстати тоже тема, которую можно обсуждать не только в рамках Java или C++.

Хорошо, ну а кроме исключений есть еще и указатели. Тут кто в лес - кто по дрова.
Есть перлы, которые создают static свойства определенного класса, дабы не мучиться в объявлениях потом.
Некоторые объявляют private PointerType myType, а потом в течение всего кода протягивают указатель на него, передавая в качестве параметра - тут тоже возникает вопрос: кто прав, у кого код лучше?
Это я щас относительно Java говорю, в Си - совсем другое дело.

 

device
Чтобы красиво и качественно писать почитай GOF.
И Влисседес лично книжку позже выпускал по тонкостям его применения.
Там приёмы красивой и практичной архитектуры как для цпп так и ява.