1. Objective C / Говнокод #13324

    −106

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    - (void) setStr:(NSString*) strT {
        if (strt) {
            [_str retain];
            _str = strT;
        }
    }

    чудо сеттер от юниора

    Запостил: torip3ng, 08 Июля 2013

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

    • На расстрел не тянет, но на розги вполне.
      10 ударов за проверку на nil, 10 за retain не той переменной и 20 за отсутствие release.
      Ответить
      • 10+10+20=40. Не положено, после сорока умрёт.
        За отсутствие release 19.
        Гуглите наказание апостола Павла.
        Ответить
    • Неужели кто-то еще вручную считает ссылки?
      Ответить
      • Вы так говорите, как будто это плохо
        Ответить
        • А что ж хорошего? Куча багов вечно вылазит из-за невнимательности разрабов. Сидишь потом разгребаешь...
          Ответить
          • В ARC столько ограничений, что его можно использовать только понимая, что ты делаешь. А понять, что ты делаешь, можно только разобравшись с подсчётом ссылок без ARC. А если ты разобрался с подсчётом ссылок без ARC, то нахрен этот ARC вообще нужен?
            И если без ARC перед вами вас полная программы, то с ним придётся проявлять паранормальные способности, чтобы понять, чтоже там происходит-то.
            Ответить
            • Если приходится проявлять паранормальне способности, чтобы понять, что происходит в коде, то проблема наверняка не в способе подсчета ссылок. Ограничения ARC знать, конечно надо, кто ж спорит. В итоге для одного и того же программиста вероятность допустить ошибку, используя ARC, ниже, чем с ручным подсчетом ссылок
              Ответить
              • Но при этом время, потраченное на поиск и устранение утечки - выше. В результате - шило на мыло.
                Ответить
                • Почему же выше? Количество потенциальных утечек меньше, и существенно меньше количество потенциальных обращений к зарелизеным объектам. Недавно приняли на поддержку проект на 30к строк кода у индусов, приложение живое еще со времен iOS 3.0. 2 дня ловили краш в одном классе, потом плюнули, поубирали релизы-ретейны, включили ARC - и все летает, никаких тебе утечек, никаких крашей. Возможно сужу со своей колокольни, но как по мне, ARC очень существенно облегчает жизнь
                  Ответить
                  • Возможно это зависит от качества кода. В своём коде мне проще считать ссылки. С другой стороны, если это код в стиле "пиздец"... Возможно, там можно и ARC заюзать.
                    Ответить
                    • Как по мне, так код должен быть такой, чтоб можно было просто удалять все [obj retain]; , [obj release], включить ARC, - и работа кода никак не изменилась. Иначе код и есть пиздец)
                      Ответить
                      • Если в проекте есть retain'ы - это уже признак того, что управление памятью в нем сделано через задницу, и в случае мигающего бага можно вылечить только вышеописанным переходом на ARC.
                        Сам тоже предпочитаю не пользоваться ARC, но держать код в состоянии, готовом к переходу на ARC за 3 минуты без геморроя. Рецептов то не так много:
                        1) (Самый важный) Для каждого класса сделать фактори метод, возвращающий autoreleased объект. Отказаться от использования - (id) initWith...
                        2) Не переопределять сеттеры. Только в краней необходимости и с особым вниманием
                        3) Инициализировать объекты-свойства только через сеттер: self.myProperty = [MyProperty propertyWith...]
                        4) В dealloc занулять все свойства: self.myProperty = nil; ...
                        Платформа cocos2d, к примеру, предполагает повсеместное использование autoreleased объектов (пункт 1), и это очень удобно. В конце концов сейчас, когда пишу что то в UIKit'е, немного бесит отсутствие метода + (instancetype) instanceWith... у большинства классов. Приходится городить alloc - init - autorelease, потому что делать alloc - init, а потом, где нибудь в конце метода release - верный путь получить проект с кучей утечек памяти.
                        Ответить
                        • > Если в проекте есть retain'ы
                          А сеттеры вы как реализовывать будете?
                          Ответить
                          • Сеттер, пожалуй, единственное место, где без retain'а не обойтись. Я имел в виду использование retain в любом другом месте для того что бы объект "не умер".
                            И, как я написал, переопределять сеттер не рекомендуется, и вообще это дурной тон.
                            Ответить
      • Конечно!
        Ответить

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