Комментарии 41
Что касаемо переменных то лично я для себя завел правило какое-то время назад — все переменные одного типа отправлять в массив.
И работать с массивами переменных.
И работать с массивами переменных.
Не очень понятно что имеется в виду. Переменные, например, одного типа int? Независимо от назначения этих переменных?
Позвольте спросить, сколько вам лет, и на чём вы пишите?
НЛО прилетело и опубликовало эту надпись здесь
a[i], конечно, понятнее, чем someVar. Но если писать на английском, то это решает проблему.
"Твое последнее задание в игре синий хабр: самым первым оставить глупый комментарий под статьей "
Вы серьезно? Это же ужасно. Если у Вас бывает так много переменных в классе (читай полей), задумайтесь, что-то пошло не так.
Ладно, если действительно необходимо создать много объектов, и поместить их даже не в массив, а в список, т.е. Вы заранее не будете знать размер массива.
И вообще, либо я Вас не так понял, либо действительно все так плохо
Ладно, если действительно необходимо создать много объектов, и поместить их даже не в массив, а в список, т.е. Вы заранее не будете знать размер массива.
И вообще, либо я Вас не так понял, либо действительно все так плохо
Нет, у меня нет темного прошлого. Как первый раз увидел компьютер «Байт», так — вжух — и стал писать идеальный код в соответствии с Шаблонами Программирования и Лучшими Практиками.
Не очень понял смысл этого каминг-аута.
Не очень понял смысл этого каминг-аута.
Плохой программист из какой угодно парадигмы сделает ужас, хороший в любой парадигме напишет вполне приемлемый код.
Один говорит — ошибки, а другой думает — опыт
Ребенок коверкает слова, придавая им часто нетривиальный смысл.
Взрослый говоит формально правильно в своей устоявшейся языковой среде.
Старик впадает в детство
C'est la vie
Самое ужасное что вспоминается это первые дни в php.
Я тогда изобрел офигенный способ сделать динамические пути с единой точкой входа.
мод_реврайт мне был незнаком, поэтому у меня точка входа была прописана как кастомная страница ошибки 404.
Апач не находил запрошенную страницу и подставлял мою страницу, а она уже разбирала что и куда.
Идея прожила наверное целую неделю))).
Но это так, на поржать конечно. Пользы от таких воспоминаний никакой.
Типичная ошибка которую совершают большинство программистов (как новичков так и считающих себя опытными) это неверное понимание сути парадигм.
1- ООП. Тяжело понять что ООП это в первую очередь SOLID. Понять SOLID тяжело. Можно пять раз прочитать описание в вики. Можно десять. Все равно первое понимание ООП будет неким механизмом собрать родственные функции в одном файле, да еще и переменных ему подсунуть. Класс из одного метода длиной в полторы тысячи строк? Да легко. (Не у меня, со знакомства с понятиям класса я больше 200 строк на метод не писал, что тоже ад). 60 методов в одном классе? Легко! К ним еще 20 параметров и ура в бой (было). Один класс, одна ответственность? Ну так у меня одна ответственность. У автомобиля одна ответственность — ехать. Так что можно сразу функции колес и двигателя в один класс.
2 — Толстые Тупые Уродливые Контроллеры. Это даже хуже чем goto. И тоже типичное понимание из определения/описания.
Таких примеров масса. Мы не понимаем. И используем не паттерн а свое искаженное понимание.
Да, а еще я люблю то что происходит с кодом без рефакторинга. Год без рефакторинга. Без остановки и осмотра всего целиком. Сейчас такие чудеса вычищаю что аж страшно. Никогда бы не написал если бы писал то что написано. Но… задача менялась, оно развивалось и вышло то что вышло.
Самая страшная ошибка новичка — до меня с этим никто не сталкивался. Есть такая чудесная библиотека в PHP. Называется VQMOD. (На самом деле подобных библиотек несколько существует т.е. это не один такой «гений»).
Автор писал «ООП и MVC» код в котором встречались контроллеры по несколько тысяч строк в одном методе.
Естественно иногда их хотелось изменить. Но не глобально, а только в этом проекте. Чтобы не потерять изменение при обновлении. Что он придумал? Дробить метод на части и переопределять? DRY и SOLID? Нее. Он написал библиотеку которая создает копию нужного кода и вносит в этот код изменения описанные в специальном формате в XML. Понимаете да? Программа изменяет свой исходный код, потому что автор ниасилил наследование. Подумать что ты не первый кому надо что-то изменить в существующем коде не меняя кода физически — не судьба. Будем сразу писать.
Я тогда изобрел офигенный способ сделать динамические пути с единой точкой входа.
мод_реврайт мне был незнаком, поэтому у меня точка входа была прописана как кастомная страница ошибки 404.
Апач не находил запрошенную страницу и подставлял мою страницу, а она уже разбирала что и куда.
Идея прожила наверное целую неделю))).
Но это так, на поржать конечно. Пользы от таких воспоминаний никакой.
Типичная ошибка которую совершают большинство программистов (как новичков так и считающих себя опытными) это неверное понимание сути парадигм.
1- ООП. Тяжело понять что ООП это в первую очередь SOLID. Понять SOLID тяжело. Можно пять раз прочитать описание в вики. Можно десять. Все равно первое понимание ООП будет неким механизмом собрать родственные функции в одном файле, да еще и переменных ему подсунуть. Класс из одного метода длиной в полторы тысячи строк? Да легко. (Не у меня, со знакомства с понятиям класса я больше 200 строк на метод не писал, что тоже ад). 60 методов в одном классе? Легко! К ним еще 20 параметров и ура в бой (было). Один класс, одна ответственность? Ну так у меня одна ответственность. У автомобиля одна ответственность — ехать. Так что можно сразу функции колес и двигателя в один класс.
2 — Толстые Тупые Уродливые Контроллеры. Это даже хуже чем goto. И тоже типичное понимание из определения/описания.
Таких примеров масса. Мы не понимаем. И используем не паттерн а свое искаженное понимание.
Да, а еще я люблю то что происходит с кодом без рефакторинга. Год без рефакторинга. Без остановки и осмотра всего целиком. Сейчас такие чудеса вычищаю что аж страшно. Никогда бы не написал если бы писал то что написано. Но… задача менялась, оно развивалось и вышло то что вышло.
Самая страшная ошибка новичка — до меня с этим никто не сталкивался. Есть такая чудесная библиотека в PHP. Называется VQMOD. (На самом деле подобных библиотек несколько существует т.е. это не один такой «гений»).
Автор писал «ООП и MVC» код в котором встречались контроллеры по несколько тысяч строк в одном методе.
Естественно иногда их хотелось изменить. Но не глобально, а только в этом проекте. Чтобы не потерять изменение при обновлении. Что он придумал? Дробить метод на части и переопределять? DRY и SOLID? Нее. Он написал библиотеку которая создает копию нужного кода и вносит в этот код изменения описанные в специальном формате в XML. Понимаете да? Программа изменяет свой исходный код, потому что автор ниасилил наследование. Подумать что ты не первый кому надо что-то изменить в существующем коде не меняя кода физически — не судьба. Будем сразу писать.
Программа изменяет свой исходный код, потому что автор ниасилил наследование.
Ух ты, а мне понравилась эта идея! Не, не в плане использовать в работе, а степенью нестандартности.
Свят, свят. Это адовый ад на практике.
Но я знаю за что мне это (мучения с тем кодом где это используется).
Вот за это.
Оказывается пять лет назад я предлагал нечто подобное, только не до такой степени ужасности, но направление глупости тоже самое. Но самый страшный мой грех в том, что меня тут на хабре тыкали носом, что это ужасно, но я настаивал). Впрочем осознал я это быстро, и в продакшн оно не ушло. Хотя в малых дозах оно пригодно). Идею в ключевых местах делать пустой класс у которого есть только имя родителя и всё, чтобы при необходимости править его, а не ядро — использую до сих пор.
Но я знаю за что мне это (мучения с тем кодом где это используется).
Вот за это.
Оказывается пять лет назад я предлагал нечто подобное, только не до такой степени ужасности, но направление глупости тоже самое. Но самый страшный мой грех в том, что меня тут на хабре тыкали носом, что это ужасно, но я настаивал). Впрочем осознал я это быстро, и в продакшн оно не ушло. Хотя в малых дозах оно пригодно). Идею в ключевых местах делать пустой класс у которого есть только имя родителя и всё, чтобы при необходимости править его, а не ядро — использую до сих пор.
мод_реврайт мне был незнаком, поэтому у меня точка входа была прописана как кастомная страница ошибки 404.Не поверите — у меня есть CMS (малоизвестная, если только в узких кругах) у которой ЧПУ основано на этом методе )
Апач не находил запрошенную страницу и подставлял мою страницу, а она уже разбирала что и куда.
Встречал VQMOD в opemcart проектах. Противная штука.
Хм. А я всегда думал что программисты живут осознанием, что вчерашний код был хуже сегодняшнего…
Узнаешь новый вариант решения, начинаешь его применять, вполне осознаешь что старый был хуже. И так — постоянно.
Узнаешь новый вариант решения, начинаешь его применять, вполне осознаешь что старый был хуже. И так — постоянно.
НЛО прилетело и опубликовало эту надпись здесь
Любой дурак может написать программу, которую поймет компилятор. Хорошие программисты пишут программы, которые смогут понять другие программисты.
Фаулер Мартин.
Всё остальное шелуха.
Стандарты. Будь то стандарты оформления кода, паттерны или другие стандарты — решают проблему читаемости кода и ускоряют разработку. Ускоряют двумя путями — когда код более понятный другим, он более понятен и тебе. Ну и дополнительно — готовые паттерны уже готовы, и можно меньше выдумывать.
НЛО прилетело и опубликовало эту надпись здесь
В "портянке" выше я достаточно подробно коснулся вопроса ПОНИМАНИЯ паттернов).
Нашел как-то свой старый свой код, который когда-то потерял, очень горевал в свое время, что не смогу использовать свои библиотеки и компоненты.
Лучше бы не находил.
Лучше бы не находил.
Когда мне было 9 лет, и я не знал, что такое алгоритм сортировки, я написал сортировку четырех элементов на Турбо-Паскале на обычных условных операторах в 150 строк в виде единого дерева. Даже тогда я понял, что так писать нельзя. И только на следующий день я узнал, что в Паскале есть такая штука — цикл.
Признаюсь. Я писал IDE редактор, разделив его на два слоя — ядро (правильное решение) и всё остальное (ой).
Под всем остальным понималась смесь модели, вьюмодели ксамл кс вьюх (дело было в впф), логики и чего то ещё( похоже мой мозг стирает такие негативные воспоминания). Неймспейсы и папки проекта были рандомными, а в одном файле могло быть до 10ти классов. И не обязательно однотипных.
Вообще ничего не было обязательным. Сальвадору дали дали студию. Зря ;)
Оно работало и его не трогали, пока, спустя два года, один проект созданный на этом монстре не стал открываться по 40 минут, а через 40 минут радостно выдавал OutOfMemory.
Последние 7 месяцев были потрачены на разделение этого барахла на 4 слоя, с юнит тестами SOLID, и MVVM. Это лучший опыт в моей жизни, хоть и на мёртвой технологии. Теперь дзен…
П.С. Я не думал что когда нибудь это всё расскажу, но раз такая пьянка… С души отлегло.
Под всем остальным понималась смесь модели, вьюмодели ксамл кс вьюх (дело было в впф), логики и чего то ещё( похоже мой мозг стирает такие негативные воспоминания). Неймспейсы и папки проекта были рандомными, а в одном файле могло быть до 10ти классов. И не обязательно однотипных.
Вообще ничего не было обязательным. Сальвадору дали дали студию. Зря ;)
Оно работало и его не трогали, пока, спустя два года, один проект созданный на этом монстре не стал открываться по 40 минут, а через 40 минут радостно выдавал OutOfMemory.
Последние 7 месяцев были потрачены на разделение этого барахла на 4 слоя, с юнит тестами SOLID, и MVVM. Это лучший опыт в моей жизни, хоть и на мёртвой технологии. Теперь дзен…
П.С. Я не думал что когда нибудь это всё расскажу, но раз такая пьянка… С души отлегло.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
13 лет плохого кода в играх