Логика программистов

Зарисовка из работы, показывающая особенности мышления программистов. Я каждый месяц покупаю в офисную библиотеку 2 книги по выбору сотрудников. Они их могут брать домой и читать. Библиотека становится большой и чтобы книги не потерялись решили сделать вкладыши в книги, которые будут оставаться на полке и по ним можно отследить у кого книга. Одна сотрудница сделала вкладыши и пошла уточнять у кого книги на руках, чтобы учесть все. Спрашивает у программиста

- У тебя дома рабочая книга есть?


- Нет


- Хорошо, значит у тебя нет рабочих книг.


- Почему это, есть. Она у меня в сумке.


- Так а почему ты сказал что у тебя нет книг?


- Ну она же у меня не дома.

Вы смотрите срез комментариев. Показать все
6
Автор поста оценил этот комментарий

Не удержался, извините


if (book.Position != Position.AtHome)

{

     return false;

}


Всё логично :D

раскрыть ветку (22)
3
Автор поста оценил этот комментарий

if (book.Position != Position.AtHome)

{

return false;

}

return true;

Иллюстрация к комментарию
раскрыть ветку (18)
15
Автор поста оценил этот комментарий

return book.Position != Position.atHome;

нубы

раскрыть ветку (17)
18
Автор поста оценил этот комментарий

return book.Position != Position.atHome;

return book.Position == Position.atHome;

чьяб корова-то мычала

раскрыть ветку (2)
3
Автор поста оценил этот комментарий

return book.currentLocation === programmer.locations.home;

раскрыть ветку (1)
7
Автор поста оценил этот комментарий
Иллюстрация к комментарию
1
Автор поста оценил этот комментарий

продолжаем перфекционировать и оптимизировать:


return book?.Position != Positions.AtHome ?? Position.Unknown;


иначе и моя и ваша версия посыпится NullReferenceException-ом :D

раскрыть ветку (5)
Автор поста оценил этот комментарий
О! Свифт! А зачем это вам точка с запятой в конце?
раскрыть ветку (2)
Автор поста оценил этот комментарий

На C# похоже, тогда и точка с запятой в тему

Автор поста оценил этот комментарий
Необязательно Свифт. Это вполне себе валидный код на карте.
Автор поста оценил этот комментарий

perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

ждем кода на брейнфаке

1
Автор поста оценил этот комментарий

А вдруг кроме возврата значения требуется дополнительная обработка объекта.

Преждевременная оптимизация - корень всех зол :D

раскрыть ветку (7)
1
Автор поста оценил этот комментарий
    Это даже не оптимизация, так как код, почти наверняка, будет сгенерирован одинаковый. Но в первом случае одним нажатием хоткея, без правок, перекомпиляции и перезапуска программы можно установить breakpoint (точку останова для отладки) на строку возврата false или true.
    Поэтому однострочный код будет заменён первым же, кто пройдётся по нему в отладкой. А скорее всего, подобное уже будет внесено в корпоративную конвенцию стиля кода, и в идеале, не пройдёт через ревью.
раскрыть ветку (6)
Автор поста оценил этот комментарий

Я вас удивлю, но поставив брейк на эту самую строчку можно увидеть результат (в msvs по крайней мере). Ни разу не видел, чтобы такие штуки разворачивали

раскрыть ветку (4)
Автор поста оценил этот комментарий

Ага, удивили, вашей невнимательностью. Прочитайте ещё раз, подумайте в чём разница между одной строчкой для обоих результатов, и двумя - одной для true, другой для false.

раскрыть ветку (3)
Автор поста оценил этот комментарий

Поясните? Интересно же, вдруг я правда чего-то не вижу

раскрыть ветку (2)
1
Автор поста оценил этот комментарий
Смысл в том, то так вы можете поставить break на строчку с возвратом только true или только false, в зависимости от того, какую ветку поведения отлаживаете. А в однострочном варианте только на любой возврат из функции, что не удобно, если функция в 99.99% случаев возвращает true, а вам нужен false или наоборот. (Есть конечно ещё conditional/data breakpoint но не везде поддерживается, не всегда удобно, и не одной кнопкой)
раскрыть ветку (1)
Автор поста оценил этот комментарий

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

Автор поста оценил этот комментарий

Ага, подавляющее большинство кода - корпоративное ПО, конечно.

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

При чет тут оптимизация - неясно.

Автор поста оценил этот комментарий

нелогично.


employeeBookStatus[i] = employee.isBookAtHome();


try{

employeeBookStatus[i]=false}

catch(StatusMissmatchException)

throw{employee.getBookPosition}

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

Сэр, используйте более свежий c# при возможности (в java кстати не знаю, есть ли такая возможность?


employeeBookStatus?[i] = employee.isBookAtHome();

employeyeBookStatus?[i] = false;


Тогда try/catch не нужен, и имхо более читабельно.

P.S. судя по именованию методов, вы имели ввиду код на java?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

java

полгода уже не кодил, свичнули на тестирование.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку