Программирование, т. 2

какой-то ты странный программист... если возвращать null, то придется везде ставить проверки на null дальше по коду или все повалится к ебеням. Уж лучше тогда кинуть эксепшен типа UserNotFoundException и нормально его обработать. Вообще return null; это в 99 случаях из 100 антипаттерн. Так же ни в одном из моих примеров нет двойной инициализации объекта.

эмпти плеер тут нахуй не надо, ибо налл в 90% случаев и есть сутью пустого игрока, там вообще всегда идёт проверка на пустого игрока - это вполне нормальное поведение программы - игрок не найден, поэтому ебенить эксепшн в той ситуации было бы глупо

 

тебе все дмитрийцифры написал, но ты бы вообще начал с того, что if (Reader.Read()) это вообще пиздец. а если у тебя запрос больше одной строчки вернет?

тупое замечание

это невозможно

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

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

Ну чувак сразу видно пишет лишь бы работало. У нас за возвращение null просто из-за того что так хочется пизды дают, надо конкретно объяснить, почему и зачем, в каком случае. Тем более он сам сказал что система очень нестабильна.

 

По поводу множества запросов, тоже не пойму зачем делать на каждого пользователя по запросу. Проще возвращать их пачкой. К томе же шарп из коробки позволяет кешировать, сделал бы кеш на 1000 игроков, дергал бы оттуда, думаю этого было бы более чем достаточно. Инвалидацию кеша можно было бы сделать по мере обращению к элементам. Если добавляется новый, то он помещается в начало очереди, последний выкидывается. Соответственно данные к которым были бы частые обращения, постоянно были бы в кеше.

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

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

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

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

Ну вот смотри, у нас в компании около 60 компонент, мы с ними только на уровне интерфейсов общаемся, если везде все данные проверять на null это будет полнейший пиздец. Везде где может быть вернут null отмеченно в документации, так как null -- это уже считай что-то пошло не так.

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

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

Ну вот смотри, у нас в компании около 60 компонент, мы с ними только на уровне интерфейсов общаемся, если везде все данные проверять на null это будет полнейший пиздец. Везде где может быть вернут null отмеченно в документации, так как null -- это уже считай что-то пошло не так.

а если проверять реальный объект или mock - то вообще охуеть можно. при чем если вариант с проверкой на налл полностью прозрачный - то с моками сложнее

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

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

Ну вот смотри, у нас в компании около 60 компонент, мы с ними только на уровне интерфейсов общаемся, если везде все данные проверять на null это будет полнейший пиздец. Везде где может быть вернут null отмеченно в документации, так как null -- это уже считай что-то пошло не так.

а если проверять реальный объект или mock - то вообще охуеть можно. при чем если вариант с проверкой на налл полностью прозрачный - то с моками сложнее

так и не надо проверять, ты просто работаешь с данными как с настоящими без ненужных проверок на null.

List<Child> children = parent.getChildren();
for(Child child : children)
{
...
}

типа такого, вот на кой фиг тут проверка на null? Таких примеров куча.

ну тут должно возвращать пустой список. это нормально, но вот при запросе парента возвращать mock, а не null - быдлокод

ну тут должно возвращать пустой список. это нормально, но вот при запросе парента возвращать mock, а не null - быдлокод

Для меня быдлокод где попало возвращать Null. Если он действительно нужен, я его верну, если единственный аргумент: так проще, то ну его нахуй.

ну тут должно возвращать пустой список. это нормально, но вот при запросе парента возвращать mock, а не null - быдлокод

Для меня быдлокод где попало возвращать Null. Если он действительно нужен, я его верну, если единственный аргумент: так проще, то ну его нахуй.

то-есть городить велосипеды вместо стандартного решения - это нормально?

На Koding.com открыли регу.

ну тут должно возвращать пустой список. это нормально, но вот при запросе парента возвращать mock, а не null - быдлокод

Для меня быдлокод где попало возвращать Null. Если он действительно нужен, я его верну, если единственный аргумент: так проще, то ну его нахуй.

то-есть городить велосипеды вместо стандартного решения - это нормально?

Ну смотри, есть какой-то мессаджЭнжен, ты можешь принудительно проверить, есть ли в нем какое-то сообщение. Если там ничего нет, то вернется null, тогда в месте где будет обработка сообщения, нужно делать проверку на null и там же возвращать какое-то системное сообщение. Так почему бы не создать EmptyMessage в котором будет храниться сообщение о том что "Новых сообщений нет", который ты можешь конфигурить как тебе угодно больше никогда не влезая внутрь кода обработчика. Или ты считаешь что и в этом слачае надо возвращать null?

проверка идет на список сообщений, а не на сообщение.а вот если мы проверяем одно сообщение - то в случае, если использовать mock вместо null - то придется показывать mock или проверять реальный ли это объект или mock

null это очень плохо, даже его изобретатель так считает

null это очень плохо, даже его изобретатель так считает

это кто же его изобрел? и почему он так считает?

это кто же его изобрел? и почему он так считает?

В цитатах такое как-то встречал:

«Я не мог устоять перед искушением добавить в язык нулевой указатель (null), просто потому, что его так легко было реализовать. Это привело к бессчётному множеству ошибок, уязвимостей и сбоев, которые нанесли ущерб, наверное, в миллиард долларов за последние сорок лет.»

Tony Hoare.

null это очень плохо, даже его изобретатель так считает

это кто же его изобрел? и почему он так считает?

я думаю, это тот же, кто придумал алгоритм quicksort. только quicksort это хорошо, а null pointer - плохо

это кто же его изобрел? и почему он так считает?

В цитатах такое как-то встречал:

«Я не мог устоять перед искушением добавить в язык нулевой указатель (null), просто потому, что его так легко было реализовать. Это привело к бессчётному множеству ошибок, уязвимостей и сбоев, которые нанесли ущерб, наверное, в миллиард долларов за последние сорок лет.»

Tony Hoare.

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

А почему нельзя возвращать false? Мне кажется это разумнее чем null

А почему нельзя возвращать false? Мне кажется это разумнее чем null

ты о строгой типизации что-то слышал вообще?

я ж быдлокодер

какой-то ты странный программист... если возвращать null, то придется везде ставить проверки на null дальше по коду или все повалится к ебеням. Уж лучше тогда кинуть эксепшен типа UserNotFoundException и нормально его обработать. Вообще return null; это в 99 случаях из 100 антипаттерн. Так же ни в одном из моих примеров нет двойной инициализации объекта.

эмпти плеер тут нахуй не надо, ибо налл в 90% случаев и есть сутью пустого игрока, там вообще всегда идёт проверка на пустого игрока - это вполне нормальное поведение программы - игрок не найден, поэтому ебенить эксепшн в той ситуации было бы глупо

 

тебе все дмитрийцифры написал, но ты бы вообще начал с того, что if (Reader.Read()) это вообще пиздец. а если у тебя запрос больше одной строчки вернет?

тупое замечание

это невозможно

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

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

так у меня просто отдельная функция на один запрос ёпт, я же не настолько долбоёб чтобы ебенить 10-15 вызовов одиночной функции

 

ну тут должно возвращать пустой список. это нормально, но вот при запросе парента возвращать mock, а не null - быдлокод

Для меня быдлокод где попало возвращать Null. Если он действительно нужен, я его верну, если единственный аргумент: так проще, то ну его нахуй.

сука ты упоротый еблан наверное

 

у меня с классом лигплеер работал только обработчик команд и класс работы с БД бота дота-лиги блядь, ты пишешь ".бан диман123456789", бот идёт в базу с селект * где ник_уебана = "диман123456789" и если такого уебня в базе нет, то он вернёт налл, а если есть - лигеплеера

 

а обработчик команд (который бтв абсолютно отдельный от работы с БД), общее звено между которыми исключительно стринг с ником и класс лигплеер любой запрос в БД по нику чекнет на предмет есть ли этот игрок вообще

 

есть варианты для упоротых:

- инстанция "пустого игрока"

- поле плеер_экзистс

- эксепшн

 

а есть вариант для нормальный людей - вернуть налл без инициализации НАХУЙ НИКОМУ НЕ НУЖНЫХ инстанций класса, потому что ИГРОК БЛЯДЬ НЕ СУЩЕСТВУЕТ, а значит и инстанции для него тоже нахуй не надо создавать

 

правильный кодер тут блядь нашёлся

А почему нельзя возвращать false? Мне кажется это разумнее чем null

ыыыыыыыыыыыыыыы

 

у меня бот был на шарпе, а не на пхп

 

а старый бот на вбс-е возвращал 0 или фолс по успотрению его первого автора, так что всё ок :tusila-zavodila: