1. ActionScript / Говнокод #7966

    −115

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    package aerys.minko.scene.node.group
    {
    	...
    	public class LoaderGroup extends Group implements IEventDispatcher
    	{
    		...
    		public static function loadBytes(bytes : ByteArray, parserOptions : ParserOptions = null) : LoaderGroup
    		{
    			return new LoaderGroup().loadBytes(bytes, parserOptions);
    		}
    		...
    		public function loadBytes(bytes : ByteArray, parserOptions : ParserOptions = null) : LoaderGroup
    		{
    			...

    minko, конечно, интересный 3д движок с нестандартными решениями, но вот такие выебоны вгоняют в ступор. я даже не знал, что такое компилится.

    Запостил: makc3d, 24 Сентября 2011

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

    • вот такой финт ушами, как return new LoaderGroup().loadBytes -- это, конечно, круто.
      Ответить
      • Поясните мысль
        Ответить
      • Вполне нормальный оопшный финт для скрытия реализации.
        Каюсь - сама так иногда пишу
        Ответить
        • опишите статичный метод, если контекст this не нужен, и скрывайте реализацию как душе угодно. а создавать "никому не нужные" обьекты - это все равно маразм, и аукается и на памяти (замусоривание), и на производительности
          Ответить
          • Из контекста нельзя узнать нужные это объекты или нет.
            Ответить
            • > return new LoaderGroup().loadBytes(bytes, parserOptions);
              вот в данном случае - создается обьект, который загружает данные, при этом данные возвращаются, а загрузчик безвозвратно отправляется в мусорный контейнер
              Ответить
              • Я вижу, может за ним тонна кода спряталась, кто знает
                Ответить
                • Но вот то что возвращает LoaderGroup а не интерфейс... Впрочем придирки это все, вполне нормальный код, даже супер прогер и не то в реальном рабочем процессе переделок напишет.
                  Ответить
                • о чем вы? полностью аналогично, но грамотно, было бы описать как LoaderGroup.loadBytes(bytes, parserOptions);
                  Ответить
                  • Если задача меняется каждые несколько дней, если планируется расширение...
                    Я такие конструкции часто пишу когда проектирую структуру, под рефракторинг. Потом они благополучно умирают, когда добавляется функционал.
                    Грамотно с точки конкретного момента, но не факт что в уме автора нету знаний о том как это все будет расширятся.
                    Ответить
                    • я думаю, при соотв. знаниях и опыте - в любой момент можно писать в меру грамотный код
                      Ответить
                      • Эмм, вы когда нибудь по двадцать часов в день несколько дней подряд кодили? Я думаю так и рождается неплохая часть эпика выложенного сюда.
                        Этот код - вполне грамотный.
                        Ответить
                        • по 20 нет, но по 16 - не так давно приходилось.... и код, хоть не полностью красив - копипасты море, но и не особо плох....
                          Ответить
                        • хмм, подискутировал бы я с вами об этом, только не здесь - а то оффтоп разводить не особо к тому же я и так тут с повышенными правами, не пристало
                          Ответить
                • кстати, с возвращением на говнокод ) что-то вас давно тут не было
                  Ответить
              • отнюдь, сударь, отнюдь. именно загрузчик и возвращается; мы это уже и обсудили тут, с gegMOPO4
                Ответить
    • Э-э-э, а что не так?
      Ответить
      • Ну, какбэ... не трудно было дать другое имя, createAndLoadBytes, например. Или хотя бы с большой буквы написать. FD вообще отказался переходить в правильную функцию по F4. А с точки зрения языка, который не поддерживает перегрузку функций, возможность называть одинаково потенциально совершенно независимые функции контринтуитивна и "needlessly confusing".
        Ответить
        • Не знал, насколько это принято в ActionScript. В других языках бывает.
          Ответить
        • Нет, не нужно было называть другим именем. Правильно называть таким именем, которое точно отражает назначение.
          Я вижу говнокод в том, что можно было сделать так:
          public const loadBytes:Function = LoaderGroup.loadBytes;

          Т.как вторая функция все равно ничего нового к первой не добавила. Недостаток - не известен тип аргументов функции. Я в таком случае делал бы:
          public const loadBytes:Function /* ByteArray->Null<ParserOptions>->LoaderGroup */ = LoaderGroup.loadBytes;

          Но это зависит от того, знакомы ли разработчики с HaXe / согласны ли они мирится с тем, что код будет не до конца проверятся компилятором и т.п.
          Но, вообще, если чесно, я не вижу надобности во второй функции - зачем, если она ничего принципиально нового не делает?
          Ответить
          • смотри внимательнее, как раз 2-я функция тут всё и делает. а 1-я просто создаёт инстанс и вызывает в нём 2-ю.
            Ответить
            • Так я и говорю, что не надо было так делать :) Функция-то все равно одна, нужно было ее изначально статической делать. Смысл писать функцию, которая ничего кроме вызова другой функции не делает от меня ускользает.
              Ответить
              • О, смысл есть. Пример — как раз парсер. В процессе рабора может использоваться множество вспомогательных функций и несколько переменных, описывающих состояние парсера. Можно все эти переменные передавать в каждую вспомогательную функцию, а можно завести класс и инкапсулировать туда данные и методы. После того, как парсер отработал, объект не нужен. По идее вторая функция (как и все вспомогательные методы, конструктор и данные) могла бы быть приватной. Но иногда полезно явно создать парсер, настроить его и иметь доступ к состоянию на случай ошибки.

                Имена, согласен, лучше бы разные использовать.
                Ответить
                • версия неплохая, но она имела бы бóльший смысл, если бы эти функции не возвращали LoaderGroup )
                  Ответить
                • А как же разделение данных и программы? Данные, если нужно, пусть хранит, функции-то размножать зачем?
                  Ответить
      • а вам не кажется, что такой способ "наследования" статичных методов, мягко говоря, попахивает?
        Ответить
    • Автор говнокода совместил Factory c Утилитным методом.. Вполне возможно сначала был статический метод а затем когда он показал несостоятельность - втихаря заменил на метод инстанса. Кошернее было бы сделать новый класс - но наверное мало времни было )
      Ответить
    • Вполне нормальный код,даже не знаю что вас смутило в нём...
      Ответить
    • показать все, что скрытоvanished
      Ответить

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