Core Data для iOS

http://habrahabr.ru/post/191334/

Понравились переведённые Андреем Шмигом главы из книги Михаэля Привата и Роберта Варнера "Pro Core Data for iOS"

Плоха ли привычка выходить с помощью return из метода/функции? И про ==

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

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

Автор советовал вместо того чтобы просто выходить при определённых условиях с помощью return не делать этого, а везде явно заключить всё в блоки, потому что это будет в будущем явно показывать: при таких-то условиях выполняется вот этот блок, а при таких-то условиях будет выполняться другой блок. Нигде не будет ни одного return на полпути, а только в конце метода/функции мы уже явно выдаём результат или просто выходим восвояси.

Интересно, что думают другие на этот счёт?

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

if (variable == CONSTANTA)
{
    // bla bla bla
}

а делать так:

if (CONSTANTA == variable)
{
    // bla bla bla
}

Потому что если по запарке напишешь не ==, а = (9 999 раз напишешь правильно, а в 10 000 раз всё-таки ошибёшься, потому что ты обычный человек, а ошибёшься в важном месте, и люди понесут серьёзные убытки из-за банальной человеческой невнимательности), то константа просто не позволит тебе сделать это физически.

Чем мне понравился язык программирования Swift

Попробовал писать на Swift. В целом язык больше нравится, чем не нравится.


Немного ломает то, что строчки не нужно заканчивать точкой с запятой. Немного ломает то, что после if необязательно писать скобки. Впрочем я их пишу, чтобы не отвыкать от своих привычек к C++ и Objective-C.


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


Ещё одна интересная особенность: nil не указывает на несуществующую область памяти (как в C++ или Objective-C), он говорит о том, что переменная равна ничему. Удивило, что даже переменной типа Int? можно присвоить nil, и что самое приятное лично для меня - эта переменная не будет равна целочисленному нулю! Это очень классно, я считаю, что это уменьшает вероятность логических ошибок в коде.

UICollectionView на iOS 6

Часа 3 ушло на то, чтобы понять почему UICollectionView совершенно не показывает своих ячеек с картинками (теплилась лишь слабая надежда, потому что снизу всё-таки была жива прокрутка). Оказалось, что фрейм был задан чуть с меньшей высотой чем нужно. И это проявлялось в моём случае только в устаревшей iOS 6 и только на iPhone. Помог только лишь тупой перебор вариантов (спасло то, что соседние UICollectionView показывали свои картинки-ячейки). Догадаться, что уменьшение высоты контрола делает его ячейки невидимыми я бы просто не смог.

Отчего приложение падает внутри блоков

Не используйте мемберы текущего объекта внутри блоков, выполнение которых происходит позже чем окружающий код. Например, выполнение блока может происходить только после того, как какие-то данные успешно скачались (через несколько долгих секунд). К моменту выполнения кода внутри блока объект self уже может оказаться удалённым из памяти приложения (то есть для него уже случился вызов dealloc метода). Если внутри блока вы обращаетесь к мемберу уже удалённого объекта, то приложение в таком случае упадёт. Вместо использования мемберов объекта заранее копируйте данные из них в локальные переменные, объявленные перед использованием блока.

Как быстро выяснить, кто виноват в том, что обычный контрол (UIView, UIImageView и прочего стандартного класса) уехал куда-то в сторону

Просто быстро на время создайте подкласс (например для UIImageView создайте его дочерний класс UIImageView2). Для этого даже не создавайте отдельные исходники, добавьте interface часть в заговолочный файл в класс того контроллера, где возникает непонятный баг. В исполняемый файл (m) добавьте implementation вашего UIImageView2 класса всего лишь с одним методом setFrame (этим методом вы переопределите стандартный setFrame-метод). Вот как это сделал я

@implementation UIImageView2

- (void)setFrame:(CGRect)frame
{
    NSLog(@"++++++ frame.origin.x = %f", frame.origin.x);
    [super setFrame:frame]; // сюда поставьте брекпоинт, чтобы выяснить какая такая "сволочь" портит фрейм вашего объекта на окне :)
}

@end

Hoochie Men на алтайской дудке