Готовы ли вы выложить свой код? (2) - Создание игр и всё, что с этим связано - Обсуждение геймдева

Дата: Пятница, 24 Мая 2019, 13:11 | Сообщение # 21

Red Winter Software

Сейчас нет на сайте

Цитата TimKruz (

)

Если кратко: оптимизации кода не должны быть во вред читаемости кода.

Цитата TimKruz (

)

Эм, где-то вычитал, что по отношению к коду "красиво" = "понятно".

Цитата

Ты прав. Лишние вызовы ни к чему. Поэтому мой игровой движок максимально прост:
Код
begin
GameEngine := TGenGECore.Create(Configuration);
GameEngine.Run;
end.

Понятно - растяжимо. Тебе может быть непонятно в силу того что твои знания недостаточны и ты просто не в состоянии адекватно оценить этот кусок кода. Не надо за уши притягивать и показывать свои сахарные обертки. Сокрытие работы не имеет ничего общего с понятностью. Те кто будут именно поддерживать твой код будут работать не с обертками а с тем что ты скрываешь за своим Create.

ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

Сообщение отредактировал pixeye - Пятница, 24 Мая 2019, 13:12

Дата: Пятница, 24 Мая 2019, 14:48 | Сообщение # 22

Разработчик

Сейчас нет на сайте

Код

Ты же на C++ пишешь? Где ООП?

Да кстати, это навело меня на мысль сделать ещё одну абстракцию по созданию данных, и добавил функцию create_computer.

Дата: Суббота, 25 Мая 2019, 00:19 | Сообщение # 23

старожил

Сейчас нет на сайте

Цитата pixeye (

)

Понятно - растяжимо. Тебе может быть непонятно в силу того что твои знания недостаточны и ты просто не в состоянии адекватно оценить этот кусок кода.

Цитата TimKruz (

)

Совсем другое дело, что понятность субъективна, это да)

Я не спорю, просто бывает менее понятно и более понятно (в самом общем смысле).

Цитата pixeye (

)

Сокрытие работы не имеет ничего общего с понятностью.

Сокрытие сокрытию рознь:
— то, что больше никогда не придётся редактировать, и имеет понятный внешний интерфейс;
— то, что постоянно падает и ломается, и при том трудно понять, как этим управлять извне.

И код свой я привёл скорее в шутку, а не как пример чего-то правильного)
У меня вообще код редко бывает правильным (в первую очередь потому, что я ничего до конца не довожу)...

Цитата pixeye (

)

Те кто будут именно поддерживать твой код будут работать не с обертками а с тем что ты скрываешь за своим Create.

Ну смотри:
— смотрим снаружи: просто, понятно (в отрыве от реализации);
— вскрываем первый уровень абстракции: по-прежнему просто, понятно (в отрыве от второго уровня);
— вскрываем следующий уровень абстракции: всё ещё просто и понятно (в отрыве от третьего уровня);
— ...
— углубляемся в самый низ: элементарные операции, понятные даже школьнику.
В чём проблема?

Проблема тут только в том, что не все могут правильно разделить проект на самостоятельные и независимые уровни. Например, я уже писал тут, что код должен работать даже отдельно от остального кода — это означает не только то, что любая из подсистем игрового движка должна запускаться отдельно от остального кода движка, но и любой существенный фрагмент кода не должен зависеть от всего остального кода (т.е. если воткнуть в другую программу, его поведение не изменится).

Как я понимаю, в этом и должно заключаться ООП. Мы создаём "объекты" как нечто, что существует само по себе, и нас не должно волновать, какие внутренности в них спрятаны (пока эти внутренности оправдывают наши ожидания). Но это возможно, только пока объекты остаются маленькими и понятными (подразумевается собственный код объекта, а не суммарно с вложенными объектами).

Ой, и вообще, разве разработка снизу вверх не решает эти проблемы? Сделали модуль, протестировали, и больше никогда к нему не притрагиваемся, только если не забудем, чем он должен был заниматься (но эту проблему устраняет понятность интерфейса и, при необходимости, документация). Вообще не понимаю, зачем копаться в кишках какого-то компонента, если проще и быстрее собрать новый из тех же фрагментов, из которых собран старый (если стараться делать проще).

Ммм... Ну вот, скажем, тот транслятор, о котором я говорил, используется всего в три шага: Create, LoadFromFile, Generate. Последняя функция принимает требуемую точку входа в скрипт, и возвращает результат трансляции/выполнения (на самом деле это скорее метаязык, он описывает только порядок слияния чего-либо с чем-нибудь, так что я не знаю, какие определения тут уместны) в виде строки. Зачем нам ковыряться во внутренностях? Только если расширять синтаксис языка, но тогда это будет уже совсем другой транслятор другого языка. Поэтому я могу использовать этот транслятор и отдельно, и в составе игрового движка, и ещё в чём-либо, где требуется нагенерировать каких-то данных из скрипта — и мне даже не нужно думать каждый раз о том, как устроен транслятор изнутри, потому что его работа абсолютно одинакова.

А вот обратная ситуация, когда у какого-то пепелаца стопицот рычагов управления (кажется, это называется "суперобъект"?), и приходится рыться в его реализации, чтобы понять, почему при дёргании за рычаг №120 отваливаются рычаги со 150 до 230, а рычаг 90 ещё издевательски посвистывает при этом (или бросает безымянный exception без внятного объяснения). Разобраться в этом всём можно, разумеется, но — зачем? Какая-то особая форма мазохизма, рыться в этом всём...

(Это основная причина, почему я пилю велосипеды и ненавижу обмазываться готовыми библиотеками. Моя мечта (одна из) — сделать свой ЯП, на котором никогда не будет чужих библиотек, и писать на нём лично. В гордом одиночестве. Что мне будет угодно.)

...мда, серьёзно же у меня бомбит.
Извинити(

Дата: Суббота, 25 Мая 2019, 00:43 | Сообщение # 24

Red Winter Software

Сейчас нет на сайте

Цитата TimKruz (

)

(Это основная причина, почему я пилю велосипеды и ненавижу обмазываться готовыми библиотеками. Моя мечта (одна из) — сделать свой ЯП, на котором никогда не будет чужих библиотек, и писать на нём лично. В гордом одиночестве. Что мне будет угодно.)

Зачем ?

Цитата TimKruz (

)

Проблема тут только в том, что не все могут правильно разделить проект на самостоятельные и независимые уровни. Например, я уже писал тут, что код должен работать даже отдельно от остального кода — это означает не только то, что любая из подсистем игрового движка должна запускаться отдельно от остального кода движка, но и любой существенный фрагмент кода не должен зависеть от всего остального кода (т.е. если воткнуть в другую программу, его поведение не изменится).

Как я понимаю, в этом и должно заключаться ООП. Мы создаём "объекты" как нечто, что существует само по себе, и нас не должно волновать, какие внутренности в них спрятаны (пока эти внутренности оправдывают наши ожидания). Но это возможно, только пока объекты остаются маленькими и понятными (подразумевается собственный код объекта, а не суммарно с вложенными объектами)

Решается через ecs. Ненужны сложные классы, интерфейсы, "объекты" , наследования и прочая муть

Есть данные, есть обработчики. На ооп языках реализуемо.
Клац

Непонятно о чем именно идет речь.
О каком коде мы с тобой говорим? О коде игры или движка?

У меня код условно разделен на три дома:

->Фреймворк и общие утилиты. Максимальное абстрактный код идущий под все проекты.
->Общие игровые системы подходящие однотипным играм. Они переносятся так же под проекты без перезаписи. На самом деле у меня таких систем оч мало. В основном это системы инпутов, простой физики и движений. И то в чистом виде обычно переносятся только инпуты.
->Специфические игровые системы под конкретную игру. Хотя архитектура позволяет скопировать все компоненты и системы в другой проект в этом нет никакого практического смысла. Они необходимы только в контексте конкретной игры и трата времени на излишнюю абстракцию в попытке сделать их "универсальными" только мешает работе.

ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

Сообщение отредактировал pixeye - Суббота, 25 Мая 2019, 01:04

Дата: Суббота, 25 Мая 2019, 18:02 | Сообщение # 25

старожил

Сейчас нет на сайте

Цитата pixeye (

)

Зачем ?

Хороший вопрос

Ну тип... Просто нравится делать что-то, что работает. Но когда юзаешь готовые инструменты, сначала тратишь уйму времени на изучение этих инструментов, а потом уйму времени на борьбу с ошибками этих инструментов, которые не можешь исправить из-за монструозности этих инструментов (при том что 90% от их функционала тебе не нужно!). В итоге ничего нормально не работает, а ты завален мануалами и не понимаешь, зачем тебе это всё нужно изучать, ломать и чинить...

Я вот, например, никак не пойму, зачем в C++ и подобные ЯПы продолжают добавлять новый функционал даже не на уровне библиотек, а на уровне синтаксиса. Зачем? Это ведь изучать нужно, а потом возиться в каше из кучи сущностей, использования многих из которых можно было бы избежать (если бы в языке их не было, либо программисты их не использовали)... Типа сначала все ополчились против "goto", мол он усложняет восприятие, но потом сделали 100500 новых фиговин, которые ничуть не лучше goto, особенно в таком количестве.

Честно говоря не понимаю людей, которые хвастаются, что такой-то ЯП умеет делать и так, и эдак, и ещё десятком инструментов. Оно, может, и удобно в ряде случаев, но потом приходится удерживать в голове кучу информации, чтобы разобрать очередной фрагмент кода. Типа: "так, а почему здесь это? а, новая функция, недавно в стандарт добавили... а это что? а, здесь использование бага десятилетней давности, понятно... а вот это, кажется, должно приводить к ошибке, ну-ка глянем в мануал... не, это только выглядит как ошибка, но формально допустимо... а это что за бред? нет, и так тоже можно..."

Вот и хочется иметь инструмент, который не имел бы в себе всего этого мусора.
И заодно — чтобы не было соблазна набрать use MagicLibrary, которая делает хорошо, но непонятно как.

А ещё меня бесят лицензии. Надеюсь, если из чужого у меня будет только "железо" (инструкции ЦП, команды BIOS, и т.д.), я не должен буду прикладывать специальный файл, в котором тщательно подлизываюсь к каждому, кто хоть как-то посмотрел на мой код? А то так ведь придётся создавать свой компуктер, только потом окажется, что транзисторы запатентованы и нужно кому-то дань нести, чтобы из них что-то паять... Остановите планету, не хочу нарушать чьи-то авторские права на Землю((

Счастье детей и домохозяек — нажимать "я принимаю лицензионное соглашение" ещё до того, как это самое соглашение успеет появиться на экране. Остальные вынуждены страдать (ну, кроме юристов, наверное).

Цитата pixeye (

)

Решается через ecs.

Entity component system? Можно было б хотя бы ссылку на Вики дать. <_<

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

Цитата pixeye (

)

Непонятно о чем именно идет речь.

Не важно, просто я со своими попытками сделать всё универсальным зашёл слишком далеко, и окончательно запутался))

Дата: Суббота, 25 Мая 2019, 18:19 | Сообщение # 26

Разработчик

Сейчас нет на сайте

Цитата

зачем в C++ и подобные ЯПы продолжают добавлять новый функционал даже не на уровне библиотек, а на уровне синтаксиса.

TimKruz, так уж обстоят дела. В си например мало что появляется. Выучил его и знаешь много лет, ничего нового не надо учить, все знания которые есть, их хватает, чтобы писать нормальный код. А в c++, вот у меня книга есть по c++17, так там удобства новые завезли. Например можно создать структуру.

Код

struct employe {
int id;
int std::string value;
int res;
};

И получить в цикле вот так значения.

Код

std::vector<employe> employee;
for ( auto const &[ id, value, resource ] : employee ) {
std::cout << id << " " << value << " " << resource << "\n";
}

То есть новые возможности языка добавляют удобства или повышают производительность. Я бы так и писал на си, что иногда и делаю, но мне нужно расти дальше и я изучаю c++.

Добавлено (25 Мая 2019, 18:20)
---------------------------------------------
TimKruz, ну как ты пробывал сделать хакерскую игру?

Дата: Суббота, 25 Мая 2019, 20:38 | Сообщение # 27

Red Winter Software

Сейчас нет на сайте

Цитата TimKruz (

)

Но я уже смирился, что мой путь — это к тем поехавшим одиночкам, которые мнят себя великими изобретателями, а на деле несут какой-то бред, в огромных масштабах (для примера, есть один форум по ИИ, так там как в дурдоме — все такие сурьйозные, а говорят в основном о совершенно бредовых вещах, далёких от практической разработки). Так-то нет особой разницы, пытается человек изобрести вечный двигатель, найти философский камень, сформулировать общую концепцию всего или запрограммировать компьютер на человекоподобное поведение... Короче, всё очень плохо у меня.

Ты просто честно-честно ответь себе чего ты действительно хочешь. И все встанет на свои места : ) Не прячься и не играй в игры разума. Все на поверхности.

ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

Дата: Воскресенье, 26 Мая 2019, 00:52 | Сообщение # 28

старожил

Сейчас нет на сайте

Цитата afq (

)

так там удобства новые завезли

Скорее НЕудобства. Я уже описал выше, почему излишнее разнообразие на базовом уровне — плохо.

Цитата afq (

)

Например можно создать структуру.

Код

struct employe {
int id;
int std::string value;
int res;
};

И получить в цикле вот так значения.

Код

std::vector<employe> employee;
for ( auto const &[ id, value, resource ] : employee ) {
std::cout << id << " " << value << " " << resource << "\n";
}

На Pascal можно проще:

Код

const
  MSG_EMPLOYEE_INFO = 'Employee #%d: %s %s (%d y.o.)';
type
  TEmployee = record
    ID: Integer;
    Name, Surname: String;
    Age: Byte;
  end;
var
  EmployeesRoom: array of TEmployee;
  Employee: TEmployee;
begin
  for Employee in EmployeesRoom do
    with Employee do
      WriteLn(Format(MSG_EMPLOYEE_INFO, [ID, Name, Surname, Age]));
end;

Ваще не понимаю, зачем нужны все эти ::, auto const &[]:, <type>, <<, >> и прочая бесовщина.
То есть разобрать и понять значение я могу, но принимать это не хочу. Больше слов — меньше неясных спецсимволов!

ИМХО, есть два вида ЯП:
1. Spider;
2. ,//\\(::,,::)//\\,
Первые можно читать и понимать как текст, а вторые нужно разглядывать, как ASCII-картинку.
Вот только если в языках первого типа на опечатку в слове укажет компилятор, то в языках второго типа мало того, что можно глазами не заметить лишний/недостающий символ, так ещё и компилятор может принять опечатку за корректный код, который приведёт к неизвестным заранее последствиям... Поэтому мне больше нравятся языки, подобные языку Ada (паскаль на максималках, еее). И читать приятнее, и пишется проще (дольше — не сложнее; проще — не короче).

Цитата afq (

)

TimKruz, ну как ты пробывал сделать хакерскую игру?

Ну я набросал такую вот фигню около 4 часов ночи:

А потом мне это надоело и я уснул под утро)

Цитата pixeye (

)

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

Скажем так, всю мою сознательную жизнь пронизывают идеи, связанные с разумными существами, не являющимися людьми в биологическом смысле слова; в особенности, идеи, связанные с робототехникой, искусственным интеллектом и т.д. Последнее преобладает за счёт того, что надежды на каких-то инопланетных/биоинженерных/потусторонних/каких угодно ещё существ нет, а вот робототехника развивается семимильными шагами вот прям щас. Это я понял ещё в детстве, наверное.

Вот только реальность оказалась в разы жёстче, чем в самых пессимистичных моих прогнозах. То, что называется сейчас ИИ, и близко не стоит с тем, о чём мечтается, при этом развитие ИИ направлено на бизнес, а это вообще противоположно моим желаниям, соответственно помощи ждать не от кого. В книгах на тему ИИ либо сплошная математика, либо философия. Собственные мои размышления упираются в концепции, которые не ведут ни к чему хорошему (ибо зачастую получается "сделаем вот так, а потом оно авось само как-нибудь"), если вообще к чему-то ведут (иногда тупо зарываюсь в философию или математику). Делать роботов же вообще не вижу смысла до тех пор, пока у меня не будет способной к самообучению программы, но и тут уже вижу, что слишком радужно воспринимаю идею "запилить роботессу" (в детстве вообще фантазировал на тему "собрать из выкинутых на свалку электронных плат", хотя когда-нибудь и такое станет возможным). В сумме вся эта безысходность загоняет меня ещё глубже в ту депрессию, в которую я вошёл давным-давно благодаря усиливающейся социальной дезадаптации и ряду других причин...

Я бы мог заняться чем-то другим (ну, не знаю, научиться рисовать кавайных аниме-тян давно хотелось), если бы увидел в этом значимость выше своей идеи-фикс (ммм, живая роботян лучше нарисованной, не так ли?). Но пока я не вижу особой значимости во всём, чем пытаюсь заниматься, малейшие неудачи заставляют меня всё бросить и углубиться в страдания ("аааа! опять как-то не так рисуется! какое же я ничтожество, даже такую бесполезную фигню сделать не могу!")...

Дата: Воскресенье, 26 Мая 2019, 05:40 | Сообщение # 29

Разработчик

Сейчас нет на сайте

TimKruz, ты же вроде писал что сделать файлы и каталоги легко. Я думал что ты это в первую очередь сделаешь. А ты за четыре часа сделал echo и exit.

Добавлено (26 Мая 2019, 05:46)
---------------------------------------------
Или ты там движок свой делал для игры?

Добавлено (26 Мая 2019, 05:50)
---------------------------------------------
TimKruz, я например когда раньше Delphi учил то код читался ещё нормально, но щас чтобы прочитать его надо вчитываться чуть ли не в каждую букву, сложно взглянуть на весь код сразу и понять что там. Я когда раньше попробывал c++, мне было сложно его запомнить и через какое то время я увидел си язык. Вот его то я и начал учить. Ну как учить. Я его обнаружил, а учить стал аж только через несколько лет. Тебе же советую учить какой нибудь язык раз в год. Ну или не раз в год, а хотя бы ещё один язык, чтобы мышление менялось.

Добавлено (26 Мая 2019, 05:54)
---------------------------------------------

Цитата

Скорее НЕудобства. Я уже описал выше, почему излишнее разнообразие на базовом уровне — плохо.

Никто не заставляет использовать стандарт 17, можно использовать базовый стандарт. Но слова, которые там написаны очень просты. auto это чтобы я не писал тип переменной, в данном случае employe, хотя и это не правильно, ну ты понял суть. Далее const это значит константа, что она изменятся не будет. Символ & указывает, что не надо копировать переменную из employee, а взять прям её в employee. Далее идёт кортеж, в котором объявлены переменные разных типов, для этого auto нужен был, чтобы переменные каждый свой тип получили.

Сообщение отредактировал afq - Воскресенье, 26 Мая 2019, 08:40

Дата: Воскресенье, 26 Мая 2019, 06:28 | Сообщение # 30

Red Winter Software

Сейчас нет на сайте

Цитата TimKruz (

)

Ваще не понимаю, зачем нужны все эти ::, auto const &[]:, <type>, <<, >> и прочая бесовщина.

Да и не надо понимать если не хочешь : )

Цитата TimKruz (

)

И про твой оффтоп.

Цитата TimKruz (

)

если бы увидел в этом значимость выше своей идеи-фикс

Исходя из поста у меня не сложилось впечатления что тебе ничего не хочется. Кажись тебе бабы хочется XD Нормальное такое желание. Роботяны и прочая хренота просто отмазы

Цитата TimKruz (

)

малейшие неудачи заставляют меня всё бросить и углубиться в страдания ("аааа! опять как-то не так рисуется! какое же я ничтожество, даже такую бесполезную фигню сделать не могу!")

Ну смотри, мы с тобой в одной лодке. Я рисовать тож не умею. И кучи вещей делать не умею. Но эт не делает меня ничтожным по отношению к тем кто умеет. Ты то должен понимать что любой навык это пот, труд и опыт.
Почему ты позволяешь себе неуважать чужое ремесло считая что у тебя вот просто так что-то должно взять и получится на одном только твоем желании?

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

Не надо быть 7 пядей во лбу чтобы быть счастливым. Не надо чего-то сильно хотеть чтобы быть счастливым. Надо принять себя и двигаться дальше. Всё нытье что ты писал - эт не ты

Это та матрица что ты себе придумал чтобы не было больно по-настоящему.

Искренне желаю тебе найти сил разобраться во всём этом.

ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

Сообщение отредактировал pixeye - Воскресенье, 26 Мая 2019, 06:30

Дата: Воскресенье, 26 Мая 2019, 07:04 | Сообщение # 31

Разработчик

Сейчас нет на сайте

TimKruz, вот смотри что у меня реализовано. Кстати для терминала выбирать лучше команды линукса, потому что врядли хакер будет пользоваться терминалом ms-dos.

Добавлено (26 Мая 2019, 07:33)
---------------------------------------------

Цитата

И читать приятнее, и пишется проще (дольше — не сложнее; проще — не короче).

TimKruz, я учил ada, но уже не помню его. Ты думаешь что только эти языки читать легко, но это может быть тебе. Я например если выучу язык, то мне будет его легко читать, но понимать код может быть сложно. Всегда сложно понять что автор имел ввиду написав несколько строк кода.

Добавлено (26 Мая 2019, 07:36)
---------------------------------------------
На видео я попытался провести трассировку маршрута до адреса 10.21.100.2, но этот адрес внутренный для компании, и его можно пропинговать только находясь либо клиентом либо сервером компании. А в моей компании, хоть и в редакторе написан адрес 10.21.100.2, но я его в код ещё не добавлял. Думаю сделать полуавтоматическое создание провайдеров и компьютеров. Пока в процессе.

Сообщение отредактировал afq - Воскресенье, 26 Мая 2019, 09:34

Xakep

Дата: Понедельник, 27 Мая 2019, 13:00 | Сообщение # 32

めちゃくちゃちゃ

Сообщений: 973

Сейчас нет на сайте

Цитата afq (

)

Готовы ли вы выложить код на github, чтобы любой желающий мог понять как ваша игра работает?

Я сейчас не делаю игры конечно, но все свои pet проекты выкладываю на гитхаб.

Цитата afq (

)

Да и как ты без общения с автором разберёшься где что добавлять?

Отладчик, реверс инженеринг

Цитата TimKruz (

)

Мне кажется, нечитабельный код пишут хейтеры begin..end из алгол-подобных языков. Ведь это они жалуются, что вынуждены писать 8 символов вместо двух. Конечно, быстрее набрать цепочку из спецсимволов, чем текст, но о том, как люди будут это читать (машине-то всё равно), никто почему-то не задумывается...

вкусовщина, мне вот например не нравится эти begin и end, болеее удобно пользоваться скобочками.

Цитата TimKruz (

)

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

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

Цитата TimKruz (

)

И я совершенно не понимаю, почему половина человечества мечтает "общаться с компьютером на человеческом языке", а другая общается с этими компьютерами на максимально нечеловеческих языках, несмотря на возможность так не делать... Можно было бы понять, если эти специальные коды было бы легче воспринимать, чем простой текст, но разве это так? Программирование ни разу не математика, мы оперируем реальными вещами (кроме случаев, когда вычисляется математическая формула, но это всегда делается для чего-то, а не просто так), так не надо втягивать сюда огромные формулы из отдельных символов.

Программирование и математика в том числе, и математика - это не просто набор символов, она тоже может быть красивой и выразительной, так и в программировании существует не одно лишь ООП, но так же и функциональное программирование, реактивное программирование, data orietned programming и каждая решает определенные проблемы, естественно, если ты не знаком с функциональной парадигмой, все что будет написано будет не понятно, хоть как ты обзови переменные (хотя конечно хорошо названные переменные и функции снизят порог), просто нужно учить новый подход. Код должен быть не только красивый и читабельный у него должны быть и другие качества, в том числе поддерживаемость, надежность, корректность, система не длолжна падать от малейшего чиха, и вто же время она должна работать корректно, ну и естественно поддерживаемость кода, я встречал не мало кода, который с виду выглядил чисто, красиво, опрятно, но черт ногу сломит чтобы понять как оно все работает, все раздроблена настолько мелко и не пойми как взаимодействует друг с другом.

Цитата TimKruz (

)

Их много. У Васи один стандарт, у Пети другой. Как им без начальника сработаться? Мы же тут обсуждаем опенсурс, в котором каждый может притащить кусок своего кода в общий проект, и никто никому не обязан. Кроме того, команда команде рознь, команда школьников без опыта работы – тоже "команда".

Обычно для open source добавляется файлик CONTRIBUTING.md, в котором и описываются правила работы с кодом, стиль кода, основные парадигмы итд, да и банально, если ты не будешь соблюдать эти правила, твои изменения просто напросто не примут.

Цитата afq (

)

С чего ты взял, что сможешь разобраться в сложном проекте, если даже в моём не можешь?

Я знаю что смогу, в сложном проекте обычно выдержанный стиль и есть определенная архитектура, и не обязательно вникать в детали всего проекта, можно сосредоточиться на определенных ее частях, я работал и котрибьютил в Intellij IDEA к примеру, у них там просто понятный хороший код, местами конечно сложно понять что к чему. Бывает наобором, большой проект, и там ничего не понятно и ридется весь день просидеть с отладчиком, чтобы понять как хоть маленькая часть работает, код бывает разный, что в большых проектах, что в маленьких и твой критерий оценки - "Если ты не разобрался даже в моем, то ты не сможешь разобраться в крупном проекте" не корректен.

Цитата TimKruz (

)

Эм, где-то вычитал, что по отношению к коду "красиво" = "понятно".

это не всегда так, бывает я знаю как решать сложную задачу, код получается громоздким, все понятно, но его много, и вот в один прекрасный день, ты просто смотришь как ту же самую задачу можно решить на функционально яп и она занимает жалкие 3-4 строчки, ты его можешь не понимать, но тебе это решение по умолчанию может показаться красивым, т.к. та же задача решается намного короче.

Цитата pixeye (

)

Тому кто тебе платит глубоко ***** красивый код или нет

Ну конкретно красивый или нет, действительно пофиг, но некоторым компаниям все же важно, чтобы код был поддерживаемый (а поддерживаемый код не всегда = красивый).

Цитата TimKruz (

)

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

Нужно просто сменить окружение, если находишься в окружении джунов, то чего ты еще ожидаешь от них? Они учаться еще и без должного менторства еще будут долго сами до этого доходить.

Цитата TimKruz (

)

Вот и хочется иметь инструмент, который не имел бы в себе всего этого мусора.

Просто не пользуйся не нужным мусором и пиши в своем стиле, скажем компании Insomniac (которая создала spider man новый) использует С++ и при этом очень сильно ограничивает функционал которым можно пользоваться, они не пользуются динамическим выдилением памяти в куче (у них свои аллокаторы памяти), не используют шаблоны, не используют исключения итд. Зато в C++ очень развитая инфраструктура и можно найти зрелые и хорошо отлаженные библиотеки, которыми можно просто пользоваться, а если не нравится интерфейс и он сильно выбивается из стиля проекта, просто создай свои обертки.

Цитата afq (

)

В си например мало что появляется. Выучил его и знаешь много лет, ничего нового не надо учить, все знания которые есть, их хватает, чтобы писать нормальный код

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

Добавлено (27 Мая 2019, 13:10)
---------------------------------------------
В принципе стремиться писать хороший читабельный код - это хорошо и в этом я полностью солидарен с TimKruz, но также надо понимать, что это не всегда возможно в принципе, бывает сложная предметная область и прятать эту сложность себе дороже, это будет просто заметанием под ковер и не решит проблемы с поддерживанием кода.

Дата: Понедельник, 27 Мая 2019, 13:36 | Сообщение # 33

Разработчик

Сейчас нет на сайте

Цитата

Xakep, ну это уже другая тема. Вопрос был в том, что такие языки как c++ много нововведений получают на каждом стандарте. А си нет. Можно ловить и сегфолты и на c++. Я к тому что язык сам легче выучить, и не придётся доучивать новые фичи. А нормальный код писать, это что с помощью языка, который легко учиться, можно писать нормальный код.

Ordan

Дата: Вторник, 28 Мая 2019, 02:18 | Сообщение # 34

Главный зомби

Сообщений: 3276

Сейчас нет на сайте

Цитата Xakep (

)

и поиметь проблемы с памятью

Я хоть и кодил когда то давно давно на плюсах но перешел на дельфи, а после еще и на шарп. И вот, я часто слышу от плюсовиков о проблемах с памятью и никогда не понимал, что за ужасы там творятся то)

TimKruz, Мой науч рук, доктор наук...., а ныне мой начальник, когда то давно мне сказал "Дима, думать вредно, лично я стараюсь делать это как можно реже". С тех пор это моя философия по жизни, кстати эта философия очень схожа с философией тайцев "сабай сабай"(вроде), что означает "Если ты не можешь на это повлиять, то зачем волноваться и тд?"
Так вот, меньше думай, больше кодь) Осознание красоты кода, собственный стиль, как и способность понимать свой и чужой код, приходят со временем.
TimKruz, И самое главное это "следи за КПД", в погоне за универсальностью, красотой и тд и тп можно усложнить решение задачи многократно) Не надо так делать) Да и вообще писать код с расчетом на дальнейшее его использование в других проектах.... Когда ты будешь делать другие проекты твой навык кодинга, всяко выше чем когда делал предыдущий проект и старый код будет для тебя просто мусором.

Цитата недели: Из-за леса, из-за гор, кишки, месиво, хардкор. (Берсерк ТВ-2)

Мои проекты ТЫК
Мои видяхи на ютубэ ТЫК

Если ты споришь с идиотом, вероятно тоже самое делает и он.

Xakep

Дата: Вторник, 28 Мая 2019, 04:27 | Сообщение # 35

めちゃくちゃちゃ

Сообщений: 973

Сейчас нет на сайте

Цитата Ordan (

)

Я хоть и кодил когда то давно давно на плюсах но перешел на дельфи, а после еще и на шарп.

Я наоборот с дельфи на плюсы перелез потом на D, но это только для своих pet проектов, на работе я на Java, Kotlin (backend) пишу и сейчас учу Scala.

Цитата Ordan (

)

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

Да нет там никаких ужасов, у новичков часто бывает так, что выделят память и не освобождают, либо удалили объект, а потом в другом месте пытаются получить доступ к нему (хотя это не только у новичков, таки ошибки даже в крупных проектах встречаются, такие как blender), просто нужно уметь работать с память и иногда пользоваться санитайзерами. Сейчас в C++ предпочтительная модель работы с памятью - это RAII и она, в общем то, решает большинство проблем связанных с памятью.

Дата: Вторник, 28 Мая 2019, 10:16 | Сообщение # 36

Разработчик

Сейчас нет на сайте

Цитата

у новичков часто бывает так, что выделят память и не освобождают,

Xakep, у меня такое было. Но это было когда я долго польовался c# и java и отвык освобождать память. Это из-за этих языков можно в си и c++ с памятью накосячить. Из-за этого ты не обращаешь внимание на память вообще. Но если постоянно писать на плюсах, то проблем быть не должно. Хотя фиг знает. Вон в gnome была утечка памяти, хотя проект не дилетанты пишут скорее всего.

Дата: Вторник, 28 Мая 2019, 17:01 | Сообщение # 37

старожил

Сейчас нет на сайте

pixeye,

Цитата afq (

)

ты же вроде писал что сделать файлы и каталоги легко. Я думал что ты это в первую очередь сделаешь. А ты за четыре часа сделал echo и exit.

Ух... Если тебя это так волнует, я потратил 2 часа 16 минут (параллельно играя в игру), и сделал не "echo и exit", а синглтон "TGameConsole", который принимает пользовательский ввод, разбирает и анализирует команды, список которых легко пополнить. Без этого обработчика смысла в дальнейшей работе не было бы, ибо даже если написать класс, работающий с файловой системой, испробовать на практике его не получится (без временного кода).

По мере создания класса, работающего с "файловой системой", я бы мог испытывать его в роли игрока, а не тестовыми вызовами. Я не говорю, что это удобнее или проще, но это нагляднее и мне так нравится больше — код начинает выполнять свою задачу задолго до того, как будет дописан до конца. Получается "игра с кодом", а это приятнее, чем делать всё в уме.

Цитата afq (

)

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

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

И потом, ЯП — это инструмент решения задач, а задач у меня тупо нет.

Всегда, пытаясь освоить новый ЯП, думал в стиле "щас чёт крутое запилю!" Время шло, а крутых идей, которые я мог бы реализовывать, на ум не приходило. В итоге бросал и возвращался к своему обычному режиму "покодить что-нибудь на паскале раз в полгода от скуки".

Скажем, изучал Java, чтобы освоить разработку под Android. Но осознал, что мне нечего делать именно на смартфоны. Для рынка? Он переполнен. Бросил Java.

Хотя чаще я всё-таки сталкиваюсь с тем, что не только я не знаю, чё делать, но и гугление не даёт ничего про реализацию моих идей. По крайней мере, простым и понятным языком, а не абстрактными формулами.

Цитата afq (

)

для терминала выбирать лучше команды линукса, потому что врядли хакер будет пользоваться терминалом ms-dos.

Меня заинтересовала идея игровой симуляции работы с ПК, а не симулятор хакера)

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

Цитата afq (

)

вот смотри что у меня реализовано

Эм... А где хлебные крошки? В линуксе же есть:
user@comp:~/user/documents/books$
Или как там, не суть. Мне кажется, это очень важная фича.

Цитата afq (

)

Всегда сложно понять что автор имел ввиду написав несколько строк кода.

Плохой автор, значит)

Цитата Xakep (

)

Глянь fasm, там тема с макросами дошла до того, что можно программы писать только из макросов, без инструкций ЦП.

И если кодить на ассемблере под Windows, то там в основном куча вызовов библиотечных процедур (invoke имяпроц парам1, парам2, парам3), хоть это и не избавляет от необходимости понимания работы процессора и ассемблера.

Цитата Xakep (

)

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

Если не ошибаюсь, функциональная парадигма отличается отсутствием классических переменных — т.е. все результаты куда-то передаются, а если и хранятся, то без изменений. Из-за этого код выглядит так:
v = Func1(Func2(Func3(Func4(1, 2, 3))));
Т.е. "Func4 сделала что-то с 1, 2 и 3, передала ответ в Func3, которая ... в Func1, которая сохранила результат работы в v". По-моему всё просто.

Так что проблема опять же сводится к названиям) Вот что это за Func4 и почему она получает 1, 2 и 3? Кто знает...

Или языки типа Forth. На них можно писать как угодно, но обычно пишут кучей сокращений из двух-трёх букв, и это нереально усложняет понимание кода. Читал что-то типа "программист разговаривает с Фортом на собственном языке", и в примерах там были читабельные имена, а реальный код... Далёк от этого.

Цитата Xakep (

)

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

Оглавление, оглавление надо делать) И по папкам раскладывать по смыслу.

Цитата Xakep (

)

можешь не понимать, но тебе это решение по умолчанию может показаться красивым

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

На счёт возможности писать понятно, но некрасиво — не спорю, но обычно так получается с маленькими участками кода, в которых грязь не мешает восприятию)

Цитата Xakep (

)

Просто не пользуйся не нужным мусором и пиши в своем стиле

Легко сказать. Трудно пересилить нежелание делать что-то вручную)

Цитата Ordan (

)

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

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

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

Цитата Ordan (

)

Когда ты будешь делать другие проекты твой навык кодинга, всяко выше чем когда делал предыдущий проект и старый код будет для тебя просто мусором.

Про навык согласен, но если уж приходится часто переписывать, лучше один раз написать и использовать. Когда навык поднимется значительно — вернуться и переписать лучше.

Но, окей, это всё абстрактные размышления, так можно вечно обсуждать)

Xakep

Дата: Вторник, 28 Мая 2019, 17:21 | Сообщение # 38

めちゃくちゃちゃ

Сообщений: 973

Сейчас нет на сайте

Цитата TimKruz (

)

Т.е. "Func4 сделала что-то с 1, 2 и 3, передала ответ в Func3, которая ... в Func1, которая сохранила результат работы в v". По-моему всё просто.

ну если в кратце то да, но там все же есть различные понятия такие как fold, map, filter, reduce, transduce плюс монады, паттерн матчинг итд. Лично я когда входил в ФП ничего не понимал по началу, было ощущение, как будто я впервые сел за программирование.

Цитата TimKruz (

)

Глянь fasm, там тема с макросами дошла до того, что можно программы писать только из макросов, без инструкций ЦП. :D

прикольно, может какнить попробую его, действительно - это совершенно не то что я привык видеть в ASM'е.

Дата: Вторник, 28 Мая 2019, 18:11 | Сообщение # 39

Разработчик