1. Java / Говнокод #7515

    +78

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    9. 9
    public class Settings {
    
    	public static String CURRENCY = "руб.";
    	
    	public static void setCurrency(String currency) {
    		CURRENCY = currency != null ? currency : "руб.";
    	}
    	
    }

    Мой проект. Можно ли считать это ГК?

    Запостил: tir, 11 Августа 2011

    Комментарии (243) RSS

    • Если это - полный текст проекта, то ничего страшного.
      Ответить
    • Ну уж если это класс с настройками, то он должен знать обо всех значениях, какие ему можно присвоить, а то конструкция вида:
      Settings.setCurrency("рубль-бубль")

      по коду будет верна, а по смыслу - нет.
      Да и у одной и той же валюты может быть несколько обозначений ("р.", "руб.", "рубль").
      Ответить
      • Точнее сказать, он должен знать у какого класса можно спросить эти значения (а еще возможно и на каком языке).
        Ответить
    • Ну ведь логично было бы сделать интерфейс Currency с методами типа getSymbol(), getShortName() и getFullName() и enum с реализациями этого интерфейса, а в конфиге хранить текущую реализацию интерфейса... public static String CURRENCY вообще убило.
      Ответить
      • а CURRENCY без final? =)
        Ответить
        • какой же это тогда конфиг, если final...
          а вообще имеет смысл изучить java i18n and l10n api:
          http://download.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html
          Ответить
          • ну заглавными буквами, вроде как, константы надо обозначать, а это какая-то сомнительная константа =)
            Ответить
    • Ещё нет. Вот когда будет где-то использоваться…
      Ответить
      • Уже активно используется. Поиск сказал в 87 местах.
        Ответить
      • а что плохого?
        Ответить
        • Если есть нетривиальный сеттер, то и геттер следует сделать (иначе кто-то установит поле напрямую). Само поле после этого должно стать приватным. Сплошь заглавными буквами обозначают константы. Повторяющееся значение "руб." лучше вынести в константу DEFAULT_CURRENCY.

          Не говоря уже о сомнительности нужности такого поля, вместо уже упомянутых стандартных средств. Но это зависит.
          Ответить
    • Можно
      Ответить
    • Не гк конечно, но лучше не делать везде такие "расчёты на будущее", т.к. создавать целый класс из-за одного поля и одного метода не хорошо...
      Ответить
    • я так и знал, что руб. = null !
      Ответить
      • setCurrency( null )

        Вот делать нам нечего валюту нулом выворачивать. Имхо лучше перегрузка.
        Ответить
        • простите, не понял вашего поста
          Ответить
          • Нахуй проверку на null я сказал.
            Ответить
            • проверка на тот случай, что если почему-то придет null, то валюта должна быть РУБ.
              Ответить
              • Проект свой, нужно делать так чтобы null не приходил.
                Ответить
                • тогда он должен не вырастать из штанишек хелловорлда.
                  в огромных корпоративных приложениях, где коду за 30 лет, нельзя уследить за всеми трансформациями, придет нулл или нет.
                  проще в одном месте поставить проверку, нежели по 1000 местам дрожать, не пойдет ли нулл.
                  Ответить
                  • В случае null нужно аккуратно бросить IllegalArgumentException. Проглатывание нуллов может привести к различного рода "магии".
                    Ответить
                    • java проглатывает нули?
                      C# автоматически кидает NullReferenceException, если кто-то пытается обратиться к нулёвой ссылке
                      Ответить
                      • NullPointerException
                        Ответить
                        • http://www.dotnetperls.com/nullreferenceexception
                          Ответить
                          • вы меня хотите потроллить? я прекрасно знаю, что это в дотнете. А аналогично в джаве - http://download.oracle.com/javase/1.4.2/docs/api/java/lang/NullPointerException.html
                            Ответить
                            • Простите, подумал вы меня исправляете.
                              Ответить
                              • нет, топик же в разделе Java
                                Ответить
                                • - C# кидает NullReferenceException
                                  - NullPointerException
                                  Что я должен был подумать, пусть даже и в топике Java раздела?
                                  Ответить
                                  • а, нет.

                                    - java проглатывает нули?
                                    - NullPointerException
                                    Ответить
                                  • Проблема в том, что NullPointerException вылезет, когда ты попытаешься вызвать какой то метод у объекта, а объекта по ссылке не окажется ( лежит null ). Но проблема ведь не в том, что нужно узнать, где мы упали на пустой ссылке, а в том, чтобы узнать, кто ее туда положил. Поэтому. if( currency == null ) throw new IllegalArgumentException( "currency can't be null" )
                                    Ответить
                                    • Проблема в том, что это уже 4 года как никому нахер не нужно
                                      Ответить
                                    • То ты с утиной типизацией проблем не видел.
                                      Ответить
      • Накаркал.
        Ответить
    • Ща будет много букаф.

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

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

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

      В итоге, было принято решение делать это обычной стрингой, т. к. дает достаточно много плюсов:
      - пользователь может сам задать в каком он виде хочет видеть валюту (USD, $, р., руб., грн.).
      - получаем дополнительную гибкость, т. к. ничто не обязывает использовать валюты. Например, можно задать у. е., или даже баллы.

      В толстом клиенте был сделан обычный комбобокс с наиболее часто используемыми вариантами (3-4 значения), а также с возможностью ввода своего значения.

      Теперь по реализации.
      Так как полноценного конфига у меня нет (см. выше), то было принято решение использовать глобальную переменную - как наиболее быстрый вариант.

      1. Почему поле, а не геттер?. По мне, Settings.CURRENCY выглядит лучше и короче, чем Settings.getCurrency(). В конце-концов, когда надо будет заменить Settings.CURRENCY на Settings.getCurrency проблем не возникнет, ибо любая IDE сможет провести такой рефакторинг.
      2. Почему поле назвал CURRENCY, а не currency? Чтобы лишний раз подчеркнуть, что значение используется как константа, не подразумевает модификации. У меня, как я думаю и у любого нормального java-кодера, не возникает желания что-нить присваивать чему-то, что написано БОЛЬШИМИ буквами. Вряд ли вы спешите что-нить присвоить SomeClass.SOMETHING. И вряд ли вы смотрите стоит ли там final или нет.
      Ответить
    • 3. Почему setter, а не прямое присваивание? Во-первых, здесь есть логика и дублировать ее нехорошо. Во-вторых, даже если бы ее и не было все равно был бы сеттер. Потому что IDE пока не умеют присвоения полям выносить в методы. И когда потребность в таком рефакторинге возникла пришлось бы славно пое..ться.
      4. Почему проверка на null? Использую jpa/hibernate, добавил колонку, гибер сам ее создаст в базе. @Column(columnDefinition="...") не люблю использовать, т. к. там надо полностью прописывать sql по созданию колонки, а другого способа задать дефолтное значение вроде как нет. Поэтому, после обновления у клиентов в колонке окажется null.

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

      Подытоживая выше сказанное: очень сложно судить о качестве кода, когда ты не в контексте. Нельзя придираться к коду только за то, что он нарушает какие-то каноны (public fields, глобальные переменные, именование и т. п.). Надо быть проще, оверинжиниринг еще никому на пользу не шел.

      П. С. Не будте разъяренными обезьянами =) (взято из книги Нил Форд "Продуктивный программист. Как сделать сложное простым, а невозможное - возможным")
      Ответить
      • раз БОЛЬШИМИ буквами, то наличие сеттера не предполагается
        Ответить
        • а если есть сеттер?
          Ответить
          • а если есть, то это значит, что мы в любой момент можем изменить поле, т.е. это НЕ константа.
            Ответить
            • если ты видишь SomeClass.SOMETHING у тебя возникает желание что-нить присвоить???
              Ответить
              • если я вижу SomeClass.setSomething(), то я делаю вывод, что есть (физически или логически) поле SomeClass.something, а SomeClass.SOMETHING - это ДРУГАЯ константа, возможно, имеющая отношение к (виртуальному или реальному) полю SomeClass.something
                Ответить
                • по крайней мере использовать на запись желания все-таки нет?
                  Ответить
                  • вы вошли в бесконечный цикл?
                    break;
                    Ответить
                    • просто я не получил четкий ответ: ДА или НЕТ =)

                      так будем присваивать? да/нет
                      Ответить
                      • SOMETHING=x; - нет
                        setSomething(x) - да!
                        Ответить
                        • а сеттер без надобности вызывать будете, если один кодите? да/нет
                          Ответить
                          • неважно, один я или нет, я не буду делать запутанные, противоречивые интерфейсы
                            Ответить
                            • т. е. вы себе не доверяете
                              Ответить
                              • Прагматичный программист не должен доверять НИКОМУ, особенно себе.
                                Ответить
                                • палку при этом тоже не стоит перегибать
                                  Ответить
                                  • Пойми, ты обзываешь поле как константу, создаёшь сеттер, не создаёшь геттер, делаешь злоебучую проверку на null и говоришь что это правильно, ибо желания делать присваивание к .ANOTHERTHING не возникнет. Но бля у этого поля есть сеттер и присваивание всё равно будет, хоть и через жопу, но будет. И какого хуя ты хочешь сделать так, что значение полю нельзя присвоить и при этом оставляешь сеттер.
                                    Убери сеттер НАХУЙ, или сделай уже геттер, а поле в private!
                                    Ответить
                                    • все верно, только нужно оставаться спокойным.

                                      чел просто упертый баран,мол, "это мой код, и я хочу писать его через жопу, лишь бы сэкономить пару байт и наносекуд, а если бы это был не мой код, я бы подумал"
                                      Ответить
                                    • Про сеттер см пункт 3. Если тебе непонятно, что там написано, то... мне тебя жалко.
                                      Ответить
                                      • жалейте, жалейте, мне-то что.
                                        вы, наверное, не очень опытный программист... Вас будет жалко потом, когда вы будете гулять по заботливо положенным собой же граблям.
                                        Ответить
                                        • я, как раз имел опыт работы, где все надо было делать по правилам...
                                          Ответить
                                          • > все надо было делать по правилам

                                            ох, как всё запущено... да нет никаких злоебучих правил, есть только инструменты и умение программиста их использовать. Вы, к примеру, пытаетесь ввернуть в стену гвоздь отвёрткой и радуетесь, что Вам такое пришло в голову, а все вокруг - унылое гавно, заворачивающее шурупы шуруповёртом.
                                            Ответить
                                            • Я бы скорее сказал, что забил гвоздь молотком, чтобы держалось, т. к. пока непонятно куда завинчивать шурупы шуруповертом. Раз вы такой мастер может предложите свой вариант решения?
                                              Ответить
                                              • Вам уже предложили несколько вариантов решения: радикальных и не очень. Смысла предлагать вам новые варианты не вижу, ведь у вас налицо синдром Not Invented Here.
                                                Ответить
                                                • Я смотрю всем почему-то стремно тут свой код выкладывать. Боитесь из комментов в обсуждения попасть? =)

                                                  По делу. Если честно - ничего толкового из вышесказанного я не увидел.
                                                  Был вариант от foGa (по ТЗ не прокатит), от вас с вводом интерфейса (я бы глянул на него) или юзания стандартных средств (не подойдут). Была рекомендация ввести геттер вместо поля. Я объяснил в пункте 1 почему использую поле.

                                                  gegMOPO4 предложил ввести константу DEFAULT_CURRENCY. Ну, может быть стоит.

                                                  Вот и все. Фактически два варианта:
                                                  - Ну уж если это класс с настройками, то он должен знать обо всех значениях, какие ему можно присвоить. Точнее сказать, он должен знать у какого класса можно спросить эти значения (а еще возможно и на каком языке)
                                                  - Ну ведь логично было бы сделать интерфейс Currency с методами типа getSymbol(), getShortName() и getFullName() и enum с реализациями этого интерфейса, а в конфиге хранить текущую реализацию интерфейса

                                                  Если объясните как они будут заинтегрированы и чем они лучше, буду очень признателен. Хотите поговорить про ваш вариант? Я буду просто задавать вопросы, а вы отвечать =)
                                                  Ответить
                                                  • Обсуждения высосаны из пальца.
                                                    Ответить
                                                  • Да, с enum мне больше идея нравиться (хотя по сути, один хер это все скомпилится в абстрактный класс и его наследников). К примеру, можно так это реализовать:
                                                    enum Currency {
                                                        RUB("руб.", "рубль"),
                                                        EUR("eur",  "евро");
                                                        
                                                        private String name_short;
                                                        private String name_long;
                                                        Currency(String name_short, String name_long) {
                                                        	this.name_short = name_short;
                                                        	this.name_long 	= name_long;
                                                        }
                                                        public String getSortName() { return this.name_short; };
                                                        public String getLongName() { return this.name_long; };
                                                    }
                                                    Ответить
                                                    • ок, enum так enum. Есть одна проблема: пользователи должны иметь возможность задавать свой вариант отображения.
                                                      Ответить
                                                      • > пользователи должны иметь возможность задавать свой вариант отображения.
                                                        Как-то это некошерно. Но если уж надо, то кто мешает добавить еще пару методов типа
                                                        public void setSortName(String name_short) { this.name_short = name_short; };
                                                        public void setLongName(String name_long) { this.name_long = name_long; };
                                                        
                                                        //Ну а так использовать
                                                        Currency.RUB.setSortName("деревянный"); //задаем свой вариант
                                                        System.out.println(Currency.RUB.getSortName()); //любуемся
                                                        Ответить
                                                        • Это просто пиздец. Енумы должны быть immutable.
                                                          Ответить
                                                          • > Енумы должны быть immutable.
                                                            Не обязаны. Вот static они факт должны быть (так и есть), а вот immutable нифига. Мож у меня конфиг в процессе работы приложения будет расширяться в рамках данной сессии.
                                                            Ответить
                                                            • В этом случае они должны быть immutable по своей семантике. Если вы собираетесь менять состояние enum'а RUB, то вам явно нужно что-то другое.
                                                              Ответить
                                                    • вообще-то, я имел ввиду что-то вроде этого:
                                                      //==================== Currency.java===================
                                                      public interface Currency {
                                                           String getSymbol();
                                                           String getShortName();
                                                           String getLongName();
                                                      }
                                                      //============== Currencies.java ====================
                                                      public enum Currencies implements Currency {
                                                          RUB(...)
                                                          // etc.
                                                      }

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

                                                      А вообще я думаю, что любые конфиги на клиенте должны отражать специфику его машины: URL для соединения с сервером, прокси сервера, предпочитаемые размеры окон, настройки логгирования. Валюты же - часть предметной области (вероятно, аттрибуты операций) и, скорее всего, должны храниться в БД. Но я не знаю деталей вашей работы и меня нет ни времени, ни желания разбираться глубже.
                                                      Ответить
                                                      • Ёптить. Кто мешает в моем примере объявить все методы abstract и определять его для каждого элемента в enum. Остается только один вопрос - нахуя зачем такое городить, если в данной ситуации это лишнее?
                                                        Ответить
                                                        • От енума наследоваться нельзя. Если нужно будет собственную реализацию Currency, это будет очень легко сделать. Енум просто даёт набор реализаций по-умолчанию.
                                                          Ответить
                                                          • где тут наследование? Обычное переопределение метода:
                                                            enum Currency {
                                                                RUB("руб.", "рубль") {
                                                                	public void setDefaultShortName() { setSortName("р."); }
                                                                },
                                                                EUR("eur",  "евро"){
                                                                	public void setDefaultShortName() { setSortName("не р."); }
                                                                };
                                                                
                                                                private String name_short;
                                                                private String name_long;
                                                                Currency(String name_short, String name_long) {
                                                                	this.name_short = name_short;
                                                                	this.name_long 	= name_long;
                                                                }
                                                                public String getSortName() { return this.name_short; };
                                                                public String getLongName() { return this.name_long; };
                                                                public void setSortName(String name_short) { this.name_short = name_short; };
                                                                public void setLongName(String name_long) { this.name_long = name_long; };
                                                            
                                                                public abstract void setDefaultShortName();
                                                            }
                                                            
                                                            //Пример использования
                                                            Currency.RUB.setSortName("рублей");
                                                            Currency.RUB.setDefaultShortName();
                                                            System.out.println(Currency.RUB.getSortName()); //реузльтат будет "р."
                                                            Ответить
                                                            • этот код определенно можно улучшить

                                                              enum Currency {
                                                              RUB("руб.", "рубль", "р."),
                                                              EUR("eur", "евро", "не р.");

                                                              private String name_short;
                                                              private String name_long;
                                                              private String default_short_name;
                                                              Currency(String name_short, String name_long, String default_short_name) {
                                                              this.name_short = name_short;
                                                              this.name_long = name_long;
                                                              this.default_short_name = default_short_name;
                                                              }
                                                              public String getSortName() { return this.name_short; };
                                                              public String getLongName() { return this.name_long; };
                                                              public void setSortName(String name_short) { this.name_short = name_short; };
                                                              public void setLongName(String name_long) { this.name_long = name_long; };

                                                              public void setDefaultShortName() {
                                                              setShortName(this.default_short_name);
                                                              }
                                                              }

                                                              setDefaultShortName - не самое удачное этого название метода, лучше было бы что-нить в стиле restoreDefaultShortName.

                                                              Вообще для моего случая данная реализация не подходит.
                                                              Ответить
                                                              • Я метод setDefaultShortName() добавил только, чтобы показать, что для каждого элемента enum можно переопределять методы. Ясен пень, что этот метод не имеет никакого смысла.

                                                                >Вообще для моего случая данная реализация не подходит.
                                                                Ждем нового говнокода вашей реализации
                                                                Ответить
                                                                • Задача: У меня обычное десктопное standalone приложение. Все что требуется - чтобы пользователь этого приложения мог через GUI вместо "руб." впечатать то что ему удобно видеть. Все, больше ничего не требуется.

                                                                  Ключевая фраза "через GUI", пользователь приложения не будет править код.

                                                                  П. С. Почему все фразу "не подходит" воспринимают как "ваш код говно"? Я ничего не говорил про код, все что я сказал, что он не подойдет.
                                                                  Ответить
                                                                • а зачем тут энумы? не излишне ли сложно?
                                                                  тем более, что без отражения их в джаве нельзя расширять
                                                                  Ответить
                                                                  • ок. енумы не катят. что катит?
                                                                    Ответить
                                                                    • начнем с интерфейса. Нужно, что бы пользователь мог вводить валюту. Ок, удобнее всего предоставить ему ввод в виде комбобокса, где он сможет выбирать из предложенных вариантов, а если подходящего нет - ввести своё. Таким у нас будет Вид.
                                                                      В Модели же для хранения достаточно будет простого поля String currency; c аксессорами и списка вариантов List<String>, который можно будет сохранять и дополнять - по желанию.

                                                                      кроме того, лучше Модель сделать сериализуемой, тогда ее будет очень просто сохранять и загружать.
                                                                      Ответить
                                                                      • интерфейс так и был сделан. В модели именно простое поле String currency. Это сделано.

                                                                        Как организовать доступ к этому значению из произвольного места в приложении?
                                                                        Ответить
                                                                        • private String currency;
                                                                          public String getCurrency() {return this.currency;}
                                                                          public void setCurrency(String currency) {this.currency=currency;}

                                                                          хотя лично мне еще нравится и "краткая" форма аксессоров:
                                                                          public String currency(){return this.currency;}
                                                                          public Settings currency(String currency){this.currency=currency;return this;}
                                                                          Ответить
                                                                          • Выражусь иначе. Поле currency лежит в объекте Model, который хранится в базе данных. Мне нужен доступ к этому полю из произвольной точки приложения. Т. е. не могу же я явно из базы каждый раз подчитывать этот объект, чтобы получить значение этого поля.
                                                                            Ответить
                                                                            • кеширование отменили?
                                                                              Ответить
                                                                              • гуд. как кешируем и где?
                                                                                Ответить
                                                                                • как раз на уровне базы данных. А, у вас JPA\Hibernate? Отлично, обращайтесь с сущностью где вам угодно и как угодно - обращение к базе происходит явно, при создании, загрузке или записи (new, create(),load(),update(),save()). Не бойтесь, при вызове аксессоров не происходит обращения к базе.
                                                                                  Ответить
                                                                                  • т. е. мне надо явно иметь доступ в любой точке приложения к Session или EntityManager?
                                                                                    Ответить
                                                                                    • нет, только к самой сущности - один раз получили, скажем, при инициализации приложения, и таскайте экземпляр
                                                                                      Ответить
                                                                                      • т. е. экземпляр получается нужен в глобальном доступе или его надо явно через кострукторы (или сеттеры) протягивать везде где надо?
                                                                                        Ответить
                                                                                        • в зависимости от архитектуры вашего приложения. Подумайте об использовании синглтона. Для уменьшения связанности почитайте о шаблонах проектирования, например, DI или даже IoC
                                                                                          Ответить
                                                                                          • di и loc - что за шаблоны проектирования?
                                                                                            Ответить
                                                                                            • Dependency Injection и Inversion of Control.

                                                                                              кстати, и для общего развития в AOP не мешало бы нос сунуть
                                                                                              Ответить
                                                                                              • Спасибо.
                                                                                                Ответить
                                                                                                • п.с. AOP - это Aspect-Oriented, а не Agent-Oriented, хотя и последнее - довольно любопытная штука. Но аспектно-ориентированное как раз больше подходит, когда нужно одинаковый код подключить в разные места кода (к примеру, обработка исключений, логгирование, тестирование)
                                                                                                  Ответить
                                                                                          • Потребности в DI пока нет, а ради одного места тащить его нет смысла. Остановился на глобальной переменной (по сути синглтон - это глобальная переменная). Получился класс Settings. Метод getInstance() не вводил, чтобы короче в коде было. Кешировать решил не весь объект, а только поле - currency. Т. е. фактически все как вы предложили. Единственная разница в именовании CURRENCY, вместо getCurrency() или просто currency(). Выбрал первый вариант, ибо короче. Пришли, по сути, к исходному коду. Ничего не изменилось.

                                                                                            Класс больше месяца не проживет.

                                                                                            Вы по прежнему считаете, что в моем случае надо реализовать полноценный синглтон с полноценными названиями методов?
                                                                                            И везде в коде иметь Settings.getInstance().getCurrency() вместо Settings.CURRENCY?
                                                                                            Ответить
                                                                                            • > Класс больше месяца не проживет.
                                                                                              тогда фтопку пляски с бубном, конечно.

                                                                                              А если писать реюзабельный код - тогда, бесспорно, Settings.getInstance().getCurrency()

                                                                                              эм, еще вопрос - у вас в классе Settings только одно поле CURRENCY?
                                                                                              Ответить
                                                                                              • пока да. но скоро будут множиться. а когда доростет до 3-4 будет ясно, что от них требуется и как их лучше оформить.
                                                                                                Ответить
                                                                                                • > когда доростет до 3-4 будет ясно, что от них требуется и как их лучше оформить.

                                                                                                  именно так. сложно сказать, как лучше, не видя кода в глаза
                                                                                                  Ответить
                                                                                                  • Подытоживая: по прежнему считаете, что код говно или уже так не уверены?
                                                                                                    Ответить
                                                                                                    • я остался при мнении, что
                                                                                                      1. ЗАГЛАВНЫМИ буквами следует называть только статические финальные поля, т.е. константы. Которые в коде НИКОГДА, ни через какие сеттеры, не меняются. Так привычно и всем, и мне же - исключения из правил очень легко забываются
                                                                                                      2. Если нам не нужно контролировать доступ к обьекту(полю), его можно сделать публичным, но при этом иметь ввиду, что он в любой момент сможет держать некорректное значение
                                                                                                      2.1. Иначе обязательно пользоваться инкапсуляцией
                                                                                                      3. Нельзя доверять никому, в т.ч. себе, т.к.:
                                                                                                      3.1.сложность проекта возрастет, дебаг станет мучительным
                                                                                                      3.2.память человеческая коротка, к тому же все мы меняемся.
                                                                                                      3.3.я не смогу код использовать повторно в других проектах или
                                                                                                      3.4.отдать кому-то на поддержку или доработку
                                                                                                      Ответить
                                                                                                      • это понятно.
                                                                                                        но, вы по прежнему считаете, что код говно или уже так не уверены, зная теперь о коде чуть больше: для чего он, как он появился, какую задачу решает и сколько по времени будет жить?

                                                                                                        хочу короткий ответ:
                                                                                                        "да" - по прежнему считаю что гавно,
                                                                                                        "нет" - в свете дополнительно полученной информации в ДАННОМ случае такой код допустим.
                                                                                                        Ответить
                                                                                                        • > это понятно.
                                                                                                          далее видно, что непонятно ))
                                                                                                          > хочу короткий ответ
                                                                                                          экий вы максималист!

                                                                                                          ДА, код говно

                                                                                                          и я бы никогда не стал так делать, а лучше бы чуть подумал о других решениях, об изменении в архитектуре, ибо
                                                                                                          ЕСЛИ ГОВНЯНОЕ РЕШЕНИЕ В ПРИЛОЖЕНИИ ВЫГЛЯДИТ ЛУЧШИМ, ЭТО ЗНАЧИТ, ЧТО ГОВНО ДАЛЕЕ, В АРХИТЕКТУРЕ

                                                                                                          но: в ДАННОМ случае программирую не я, а вы, и вы же все равно сделаете по своему, и вам же потом расхлебывать

                                                                                                          п.с. я бы никогда не взял ваш код на поддержку, "в свете дополнительно полученной информации" о том, что вы прибегаете к таким нестандартным решениям,
                                                                                                          в ходе которых мне пришлось бы ломать голову, что вы здесь имели ввиду, и на каждой строчке спрашивать вас, а можно ли так делать, ничего не поломав
                                                                                                          Ответить
                                                                                                          • > ВЫГЛЯДИТ ЛУЧШИМ
                                                                                                            Не лучшим, а обоснованым. Я нигде ни слова не написал, что это крутое решение. Что это единственное правильное решение. Я говорил лишь то, что это - приемлемое решение.

                                                                                                            > и я бы никогда не стал так делать
                                                                                                            т. е. то что вы писали в постах выше - это вам на ухо нашептали?
                                                                                                            Ответить
                                                                                                          • >ЕСЛИ ГОВНЯНОЕ РЕШЕНИЕ...
                                                                                                            Не нужно кричать. Мы вас слышим.
                                                                                                            Ответить
                                                      • я особо и не прошу разбираться, меня код не особо интересует. больше последовательность действий. У меня обычное десктопное standalone приложение. Все что требуется - чтобы пользователь этого приложения мог через GUI вместо "руб." впечатать то что ему удобно видеть. Все, больше ничего не требуется.
                                                        Ответить
                      • >так будем присваивать? да/нет
                        Я в своём паскале или бейсике в лёгкую присвою в SOMETHING новое значение. У меня руки чешутся сделать какую-нибудь гадость, если это не запрещено.
                        Ответить
              • Главное - есть ли возможность это сделать. На желаниях программиста далеко не уедешь.
                Ответить
                • Я над проектом один работаю. Я сам себе доверяю. Я себя контролирую. =) Это не Public API для широких масс.
                  Ответить
                  • себе тоже нельзя доверять. Вот через пару лет забудете, как связаны "константное" поле и сеттер - что, в принципе, логично. А если проект разростется - то еще и не сразу найдете причину.
                    Ответить
                    • когда будет ясно как организовать конфиг - я организую конфиг, и переведу этот код на нормальный конфиг, сейчас из-за одного поля городить хер пойми что я не буду, т. к., повторюсь, не до конца понятно каким критериям этот конфиг должен удовлетворять.
                      Ответить
                      • Хорошая у вас позиция. Раз уж не понятно, что мне нужно - напишу говно, понятное только мне, ибо один фиг переписывать. А на ГК одни придиры и параноики.
                        Ответить
                        • Во-превых. Это только мой проект. При работе в команде я бы сделал как минимум геттер.
                          Во-вторых. По вашему лучше что-то придумать, нах..чить кучу кода, чтобы потом все равно его переписывать?
                          Ответить
                          • > По вашему лучше что-то придумать, нах..чить кучу кода, чтобы потом все равно его переписывать?
                            вы как раз этим и занимаетесь.
                            Ответить
                            • Я придумал всего один класс и не более 20-30 строк кода. Предложите лучшее решение!
                              Ответить
                              • можно и в 1 строку а ля перл написать, но зачем экономить, в ущерб понятности? Уж явно, если будет геттер, это не скажется на производительности.
                                Ответить
                                • Ммм... Про геттер читать пункт 1. Решение обдуманное. Претензия только по геттеру? Потому что так не принято?
                                  Ответить
                                  • не просто не принято, а непривычно и идет вразрез с привычками.
                                    вон, многие тоже думали, что никто не будет лазать по "секретным" урлам, а Яндекс взял, и проиндексировал все к чертовой матери.

                                    в книге "Code Craft" даже отдельная глава была: не делайте предположений!
                                    Если есть возможность сделать нехорошую вещь, будьте уверены, что вы сами или кто-то другой ее сделает. Сделайте, что бы вы НЕ МОГЛИ сделать глупость, позже не раз порадуетесь
                                    Ответить
                                    • идет вразрез с привычками - похоже это главный фактор в этом деле. Нам всегда прививали, что хорошо, а что плохо. Мы готовы с пеной у рта защищать свою позицию, потому что мы так делали всегда, нас так учили, потому что это "правильно". А все кто делают не так - они ущербные, они ошибаются, они неправы. Мы должны обратить их в свою веру. Мы не пытаемся понять их точку зрения. Мы не задаемся вопросом: а может он прав? Мы слепо верим в то, чему нас учили. Мы крайне редко (а многие и никогда) задаемся вопросом: почему именно так? Почему, например, надо слепо следовать спецификации Java Beans? И таких вопросов очень много. И не всегда на них есть ответы.
                                      Ответить
                                      • важный момент - со СВОИМИ привычками, не чужими.
                                        А, в принципе, и чужими, если код придется допиливать кому-то другому.
                                        Ответить
                                        • Напишу еще раз: я один работаю над проектом, это мой проект. Других не будет. Уже раз 10 наверное это писал.

                                          JavaBeans, к примеру, групповая привычка. Причем почти никто не знает почему надо делать именно так, но все так делают.

                                          И еще. У меня имена всех тестовых методов в юнит тестах написаны в руби-стиле: маленькими буквами через подчеркивание. Мне, как я полагаю, положен расстрел за такие святотатства!

                                          С другой стороны: что легче читать?
                                          authorNameShouldBeSpecified
                                          или
                                          author_name_should_be_specified
                                          Ответить
                                          • У меня такое чувство, что автор - тролль!
                                            Ответить
                                            • когда нечего сказать - лучше молчать, чем переходить на личности =)
                                              Ответить
                                              • ну, троллю-то всегда есть что сказать, не так ли, tir? ;)
                                                Ответить
                                          • >JavaBeans, к примеру, групповая привычка. Причем почти никто не знает почему надо делать именно так, но все так делают.

                                            Не надо обвинять всех в собственных грехах. Почитайте Core Java для начала, если не знаете, зачем нужны соглашения JavaBeans.

                                            > С другой стороны: что легче читать?

                                            в контексте наличия в Java поддержки пространств имён в виде пакетов и классов оба имени - гавно. Больше двух-трёх слов в имени переменной практически никогда не нужно.
                                            Ответить
                                            • >в контексте наличия в Java поддержки пространств имён в виде пакетов и классов оба имени - гавно

                                              если бы вы внимательно прочитали написанное, то вы бы увидели " имена всех тестовых МЕТОДОВ".

                                              Насчет JavabBeans. Для многих JavaBeans не более чем: если есть поле, то для чтения использовать getField, для записи использовать setField(value).
                                              Ответить
                                              • > имена всех тестовых МЕТОДОВ
                                                для которых класс является пространством имён, а для класса пространством имён является пакет

                                                > для многих JavaBeans не более чем
                                                Не любого более-менее квалифицированного Java-программиста JavaBeans - технология, включающая помимо соглашений об именовании (обычных и boolean полей, полей - массивов) механизмы интроспекции, редакторов свойств, событий смены состояния, интеграции с IDE и ещё очень много всего. Просто в промышленности из всего многообразия лучше всего прижились соглашения именования.
                                                Ответить
                                                • >Больше двух-трёх слов в имени ПЕРЕМЕННОЙ практически никогда не нужно.

                                                  Из-за этой фразы я сделал акцент на слове "методов". Насчет имени переменной длинее 2-3 слов - соглашусь. Насчет названия тестового метода - не соглашусь. Думаю этот вопрос можно закрыть.

                                                  Насчет JavaBeans. Хорошо сказали =) Боюсь, что здесь все считают, что они как минимум "более-менее квалифицированные программисты". Надеюсь, ваш ответ подскажет некоторым из них куда надо посмотреть для общего развития. =)
                                                  Вопрос также закрыли, а то что-то от темы отошли.
                                                  Ответить
      • Спасибо, теперь ясно — говнокод!
        Ответить
      • Печальные и длинные истории нужно постить на каком-нибудь другом сайте типа личного бложика. Как минимум странно постить код на ГК, а потом обижаться и удивляться, почему его считают ГК. А ведь код - гавно, как ни крути.
        Ответить
        • я не обижаюсь =) Тут же все программисты от Бога =)
          Пример я привел лишь для того, чтобы показать, что каждый шаг был обдуман и обоснован.
          Ответить
          • > Тут же все программисты от Бога =)
            встречаются и от Дьявола = )
            Ответить
            • Продам душу за умение кодить на Java, ага.
              Ответить
              • что бы потерять душу, не обязательно ее продавать. достаточно не уметь ее ценить )
                Ответить
            • Кто-нибудь знает, почему есть язык программирования Ада, но нет языка программирования Рая? Или он всё-таки есть, но тщательно скрывается?
              Ответить
              • в Аду-то веселее
                Ответить
              • Язык Рая есть. (Русский Алгоритмический Язык РАЯ)
                http://ru.wikipedia.org/wiki/Русский_алгоритмический_язык
                Ответить
                • Спасибо! А ведь именно на этом языке были написаны алгоритмы в школьных учебниках по информатике. Только мне в голову не приходило, что его название так сокращается.
                  Ответить
      • Cool story, bro.
        Ответить
    • Унылый тролль =(
      Ответить
    • Читал-читал и заебался. Уважаемый, нахера ж было постить ваш код сюда и спрашивать не говно ли? Какая вам суть разница, если вы тут в стопятиста комментариях доказываете что проект ваш и только ваш на веки? И на каждую уместную или не уместную попытку сказать вам, что же не так в вашем коде, вы приводите одни и те же аргументы... Вобщем да, "Унылый тролль =(" и "спасибо, поржал" (:
      Ответить
      • Согласен, тред tl;dr
        Ответить
      • >Уважаемый, нахера ж было постить ваш код сюда и спрашивать не говно ли?
        Я всего лишь хотел показать, что не всегда то, что на первый взгляд выглядит говном - действительно говно. Часто незнание контекста позволяет кричать, что код говно. Я, например, редко ставлю +/- в темах, т. к. однозначно определить качество кода чаще всего достаточно тяжело. А ставить "+" или "-" без аргументации - это несерьезно. А когда просишь объяснить или сказать конкретно как надо - все сводится к увиливаниям и всячески отмазкам.

        >Какая вам суть разница, если вы тут...
        Мне и нет никакой разницы =) Все это постилось только ради см. выше

        >И на каждую уместную или не уместную попытку сказать вам, что же не так в вашем коде
        Дайте пж номера комментов с уместными попытками, хотя бы парочку. Буду очень признателен.
        Ответить
        • > хотел показать, что не всегда то, что на первый взгляд выглядит говном - действительно говно

          Думаю, у вас это ни разу не получилось. Со временем и у вас произойдёт эволюция от "Бля, какой заебатый код я написал: теперь всё работает и всё, сука, так запутанно, я тащусь!" до "Фуф, надеюсь, теперь этот код поймёт даже дебил".
          Ответить
          • Как раз таки эволюция идет полным ходом. Стояла простейшая задача, и я решил еще простейшим способом. Я знаю, что это выглядит не очень, но оно работает.

            Проблема более-менее квалифицированного программиста в том, что он умный. И из-за этого ума он часто не видит простых решений, ему сразу видятся иерархии, он видит это в объектах, он уже видит архитектуру. И часто он ее внедряет. Он просто разучился думать просто. Ему обязательно надо чтобы было ООП, и максимальная гибкость для будущих поколений. Чтобы все конфигурялось вдоль и поперек, чтобы все расширялось без геммороя. Именно более-менее квалифицированый программист чаще всего при простой задаче "добавить возможность задавать мобильный телефон для клиента" сделает не такую реализацию:
            class Person {
            ...
            private String mobilePhoneNumber;
            ...
            }

            а такую:
            class Person {
            ...
            private List<Phone> phones;
            ...
            }
            class Phone {
            private PhoneType type;
            private String phoneNumber;
            private String notes;
            }

            enum PhoneType {
            MOBILE, HOME, WORK
            }

            потому что он уверен, что эта гибкость пригодится в будущем: ведь теперь можно задавать несколько телефонов разного типа да еще оставлять примечания для каждого из них!

            Проблема в том, что в 90% это не нужно, а сопровождать это приходится. Причем согласитесь, что с 1-й реализации перейти на 2-ю не представляет особого труда. Самое интересное, что до 2-й реализации скорее всего дело никогда и не дойдет.
            Ответить
            • Вы гордитесь своей неопытностью и путаете чуть более "осведомлённого" неопытного программиста, который пытается запихать шаблоны и "лучшие практики" куда угодно, и программного инженера, который всегда выбирает наиболее с его точки зрения подходящие для работы инструменты и модели.

              ООП и Java не пуп земли. Для многих задач python или ФЯП подходят лучше, чем Java.
              Ответить
              • Тема про Java, поэтому и было упомянуто ООП.

                >и программного инженера, который всегда выбирает наиболее с его точки зрения подходящие для работы инструменты и модели
                не поверите - я их и выбрал. А вы почему-то считаете, что я неопытный программист, который наворотил говна и пытается вам доказать, что написал идеальный код =)
                Ответить
                • > вы почему-то считаете, что я неопытный программист, который наворотил говна

                  И, судя по всему, не я один так считаю. Может, стоит задуматься об этом?
                  Ответить
                  • может вам стоит задуматься об этом?
                    Ответить
                  • Не кормите тролля, позазуста
                    Ответить
                    • С голоду ж помрёт.
                      Ответить
                    • Вы спрашиваете почему кормят тролля? Многие мечтают увидеть лопнувшего тролля, КРОВЬ КИШКИ ПО СТЕНЕ ПО ПОТОЛКУ, а также самое главное: освободившееся от оболочки дерьмо.
                      Ответить
            • видимо, вы все-таки не очень опытный программист - потому, что все то, о чем вы сказали, свойственно "продолжающим" программистам, которые не так давно познали тайны ООП.
              А профессиональный программист свято следует заповеди "НЕ усложняй (без надобности)".
              Ответить
              • и где я усложнил? мое решение сложное???
                Ответить
                • это я возражаю на ваше "Он просто разучился думать просто" - нужно подбирать наиболее подходящее решение - благо, их великое разнообразие, что бы не лепить мутантов самому
                  Ответить
                  • "Он" - это не все, а большинство. Я вот о чем.
                    > нужно подбирать наиболее подходящее решение
                    именно этой мыслью я и закончил свой пост
                    Ответить
                    • разве что, оригинальность вашего решения позже выйдет вам же боком. (хотя, может, аппликушка умрет раньше)
                      Ответить
        • > Я всего лишь хотел показать

          Кстати, ГК - не лучшее место для демонстраций и доказательств. Сюда люди приходят поржать и расслабиться, а не читать "многабукаффные" рассуждения о мотивах, которые подвинули вас на говнокод.
          Ответить
          • показать все, что скрытоПросто я всегда думаю о людях в лучшем свете и пытаюсь их понять. Поэтому когда регался, думал, что тут люди умные, и ржут по делу. А тут чаще всего смех без причины. И очень много ЧСВ.
            Ответить
            • Нет, вы надеялись, что все оценят вашу "находчивость". А ЧСВ тут у всех с лихвой, в том числе и у вас.
              Ответить
              • тут не было находчивости. Просто хотел показать, что то, что выглядит ГК на самом деле может быть обдуманым решением. И прежде чем начать плюсовать и ржать, предварительно надо задуматься: в каких случаях этот код будет работать, а не как его поломать. Почти у всех изначально негатив: надо этот код поломать, любой ценой. При взгляде на код первоначальная предпосылка должна быть не "автор дебил" (что свидетельствует как раз о СЧВ), а "автор умный человек". Лучше переоценить автора, чем недооценить.
                Ответить
                • Уверяю, через год вы взгляните на это и удивитесь, какое же ГК вы написали. Обдуманно.
                  Ответить
                  • уверяю, через месяц уже этого кода не будет. почему вы уверены, что он проживет год?
                    Ответить
            • Вы разочаровались и теперь нас покинете?
              Ответить
              • до следующего вброса "гениального" говна
                Ответить
              • недождетесь =) Иногда проскакивают в комментах здравые мысли, да и в коде иногда что-то прикольное бывает.
                А вообще - я несу добро, и буду активно пропагандировать отвечать за свои слова! =)
                Ответить
                • У меня порой ощущение, что вы такой же смайлофаг как и Олерожа. Особенно когда дело доходит до столкновений двух мнений xD
                  Ответить
    • показать все, что скрытоЧеловек без стереотипов. Уважаю. Идёт рядом с течением, обдумывая каждый стереотип и привычку людей: "А действительно ли это полезный стереотип?". Придёт время, может он согласится с частью стереотипов, а сейчас пытается все понять самостоятельно, а не слепо копирует от общества.

      Да, за такое поведение - жизнь карает, но он пока молод и этого не знает.

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

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

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

      ПС: А ещё он дрочет. Это одна из черт самодостаточности. Любая мания величия или независимости от общества подкрепляется этим "пороком".
      Ответить
      • > А ещё он дрочет
        Все дрочат
        http://mf0.me/wps/2009/10/06/onanizm/
        Ответить
        • >Все дрочат
          Спс, кэп. Может на этом основании автор пасты и сделал вывод)
          Ответить
      • > а сейчас пытается все понять самостоятельно, а не слепо копирует от общества.
        типичное поведение подростка, который пытается быть "не как все", а в итоге сваливается в кучу "всех".

        особенно вредно сначала привыкнуть что-то так делать, потом пойти вразрез с привычкой, потом опять делать по-старому (заставят же). А потом открыть код и смотреть в него как баран на новые ворота: "какого хера не работает??"
        Ответить
        • >типичное поведение подростка
          Что то кэпов последнее время развелось. Или вы хотите намекнуть, что tir подросток?
          Ответить
      • > а не слепо копирует от общества
        если в обществе принято жрать говно, я НЕ СОГЛАСЕН СЛЕПО КОПИРОВАТЬ от общества.
        Ответить
        • Сообщество отбирало и культивировало решения десятки лет, их достоинства и недостатки хорошо изучены и учтены в библиотеках и инструментах разработки. И тут на сцену выходите вы и обвиняете всех в говноедстве. Вы Д'артаньян. Остальные - злая и безликая масса говна.
          Ответить
        • >я НЕ СОГЛАСЕН СЛЕПО КОПИРОВАТЬ
          Я это в пасте уже написал.
          Ответить
        • Почему ты не высказываешь несогласие? Неужели дрочишь?
          Ответить
    • нужно отдать должное автору - более полусотни комментов с разными людьми об одном вопросе, а он все равно не сдался )

      формулируя иначе, он же скомбинировал разные подходы в одном,
      1. выложил это на ГОВНОКОД(!), расписавшись при этом, что сделал говно
      2. и с пеной у рта стал всем доказывать, что это решение оправдано, т.е. дрочить на него = )
      Ответить
      • Автор страдает хернёй и троллит вместо того, чтобы наконец уже начать работать. Очевидно, что он просто получает удовольствие от бесконечных споров и раздражения собеседников.
        Ответить
        • > просто получает удовольствие от бесконечных споров и раздражения собеседников
          это называется "психологический вампиризм"
          Ответить
        • > раздражения собеседников.
          Если вы испытываете раздражение - у вас комплекс. Займитесь самоанализом. Причина раздражения всегда находится внутри нас.
          Ответить
          • Когда я вижу, когда кусок говна выдают за мега-хитрый ход уверяют в своей правоте, я раздражаюсь. Наверное, я болен.
            Ответить
            • Вообще-то да, тут тролль прав. Раздражаться из-за того что какой то говнокодер наговнокодил и пляшет это...
              Ответить
            • Заметьте, я нигде не писал, что мой код мега-хитрый и это единственное правильное решение. Это вы сами себе надумали. Я лишь объяснил почему я написал именно так. А вы приняли на свой счет. Самоанализ вам поможет, может быть...
              Ответить
            • Прописываю себе два часа кодотерапии.
              Ответить
              • Раздраженным лучше не кодить. Лучше сходить прогуляться. Можно в офисе прибраться, цветочки полить. На турничок залезть в конце-концов.
                Ответить
                • На самом деле мне абсолютно похеру. Код ваш, делайте с ним что хотите. Увидел бы такое в своём проекте - надавал бы ай-яй-яев и запостил бы сюда.
                  Ответить
                  • Может кинете исходники посмотреть вашего проекта? Хотя бы пару нетривиальных классов. Просто любопытно позырить.

                    Было бы похеру - еще вчера закрыли тему.
                    Ответить
                    • Исходники проекта защищены авторским правом фирмы, в которой я работаю, и я подписал соглашение, что не буду их распространять. В открытом доступе моего творчества мало, можно поискать в Apache POI (3.8 beta3) и на github.com (ник такой же, но там только довольно убогие поделки). Кстати, вроде 200 комментарий.
                      Ответить
                      • к сожалению 201-й =)

                        На гитхабе с удовольствием посмотрю.
                        Ответить
                      • Позырил по диагонали gitoscope. Очередной код с обработкой ошибок можно запостить сюда, таких здесь уже с десяток наверное есть =)

                        Мое мнение: выглядит так, как будто написано, чтобы как-то работало, чтобы можно было делать UI часть. Коду предстоят рефакторинги, допилы. И покрытие тестами. Сильно сомневаюсь, что это конечные варианты классов. Скоро будет причесывание этого всего.
                        Ответить
                        • Это микроскопический проект, который написан для обката maven, spring mvc и jgit в емаксе за несколько вечеров. Как раз с обработкой ошибок там всё нормально: ошибки логгируются, а все эксепшены, которые реально могут возникнуть по вине пользователя, пробрасываются и мапятся средствами spring в соответствующие странички. Перлы возможны, да. Я особо им не занимаюсь, мне на работе хватает.
                          Ответить
                          • catch (Exception e) на этом ресурсе почему-то не любят, тем более внутри try делать throw new Exception(). Где-то тут недавно холивары шли на эту тему. Лично я не вижу в этом ничего плохого.

                            Мне непонравился момент, что
                            try {
                            ...
                            setHeadAsStart(repo, revWalk);
                            setUpFilter(revWalk, filter);
                            ...
                            return results;
                            } catch (Exception e) {}

                            в методах setHeadAsStart и setUpFilter возникающие ошибки глушатся намертво (с логированием). При этом основной метод отрабатывает как ни в чем не бывало. Т. е. можно получить не те данные которые просили.
                            Ответить
                        • > Сильно сомневаюсь, что это конечные варианты классов

                          Любой код, даже хороший, постоянно модифицируется. Как только модификации закончились, проект начинает умирать.
                          Ответить
      • показать все, что скрытовсе чего я хотел достичь - это показать, что код до того когда вы что-то о нем знаете выглядит полным говном, а после того как будете знать что-то о нем - уже не говном, а просто некрасивым. Для чего? Для того, чтобы когда постят новый ГК, вы включали голову ДО того как зафигачите "+" или "-". А после того как зафигачите, то не поленитесь написать коммент почему считаете так. Можете считать это провокацией.

        Я не провозглашаю себя мессией. Мне не надо, чтобы вы сказали: "веди нас к свету", мне вообще глубоко параллельно какие чувства я у вас вызываю, меня это не волнует. Моя цель описана в 1-м абзаце. Я никого не учу.

        Отвечаю по пунктам.
        1. > расписавшись при этом, что сделал говно
        Я нигде не писал, что накодил говно. Предложеное вами решение ничем принципиально не отличается от моего. Никто так и не смог предложить вообще никакого решения (кроме вас). Хотя это был бы лучший аргумент, вместо того чтобы переходить на личности.

        2. Дрочить не надо - сотретесь. Я ничего никому не доказывал. Я просто сказал, ПОЧЕМУ код написан именно так. Почему из моего объяснения вы сделали вывод, что я вас учу - это ваша проблема, разбирайтесь в себе, почему вы так это воспринимаете.
        Все чего я ожидал - это то, что после прочтения моего объяснения вы просто сделаете для себя какие-то выводы, и примите это или нет.
        Ответить
        • 1. на говнокод постят код-говно, прочтите заголовок вверху сайта. Вопрос в том - унылое или нет. Исходя из этого и нажимают +\-
          2. все это пройденный этап - я уже писал большими буквами.

          В общем, тред клозет. поржали и разбежались
          Ответить
          • давайте еще 20 комментов, до 200 догонем
            Ответить
            • тред клозет. хватит дрочить, кончайте уже
              Ответить
              • А может автор и прав? Зачем делать геттер если он не нужен?
                *trollface*
                Ответить
                • да, и зачем писать маленькими, если можно написать большими, и тогда у меня не возникнет желания........
                  petrosyan.jpg
                  Ответить
        • У тебя говнокод и в контексте и без контекста.
          Ответить
        • В данном случае ровно наоборот. Был просто некрасивым, а как узнали «что-то» — стал безусловным говном.
          Ответить
    • Код - говно.
      Автор - тролль.
      Тема - хуйня.
      Ответить
      • унылое говно
        унылый тролль
        хуйовый флуд
        Ответить
      • Землю - крестьянам.
        Фабрики - рабочим.
        Деньги - кондуктору.
        Ответить
      • КГ/АМ по-новому зазвучал, по-говнокодовски. Забыл еще добавить, что тема хуйня из-за отсутствия сисек.
        Ответить
    • Толпа всегда права – берёт количеством она =)
      Ответить
      • Миллионы мух не могут ошибаться.
        Ответить
    • 200 сообщений, тема себя исчерпала.
      Ответить
    • Обогатился новыми мемами: «У меня обычное десктопное standalone приложение» и «Это только мой проект».
      Ответить
      • Надо потом собрать цитатник говнокода.
        Ответить
      • И что вам не понравилось в этих фразах?
        Ответить
    • tir
      Чаще обращай на мнения людей, но я тебя плюсую. Ты прав.
      Ответить
      • Я всегда прислушиваюсь к мнениям людей, которые аргументированы.
        Ответить
        • /me представил себе аргументированных людей.

          Ой-ой.
          Ответить
          • Гы, у вас еще и с русским языком проблема? Вы хотите об этом поговорить? =)
            Ответить
    • ну и срач
      Ответить
    • показать все, что скрытоЕсли честно, со временем я переметнулся на сторону автора. Это действительно хороший метод. Не важно какая у поля реализация!
      1. SOMETHING будет выглядеть константой в глазах пользователя и это правильно.
      2. setSomething() будет изменять эту константу и этот метод нужен, т.к. необходима, нет, НЕОБХОДИМА проверка на null.
      3. getSomething() совершенно не нужен! Something можно только устанавливать, а читать можно SOMETHING - независимую константу.
      *trollface*
      Ответить
    • Атценити код!!
      Ответить
    • @tir запостил это под впечатлением от Productive Programmer (ISBN-10: 0596519788), инфа 100%
      Ответить
    • показать все, что скрытоvanished
      Ответить

    Добавить комментарий