многие пользователи советовали нам включить PvP-сражение в один из начальных этапов обучения. Когда мы сформировали тест-группу и провели эксперимент, оказалось, что большинство игроков не готовы к сражению на первом этапе игры [...] поэтому пользователи уходили как раз на этапе первого сражения.
И вывод такой: пользователь не знает, чего хочет, пока не увидит, что получил. Поэтому лучше десять раз подумать, прежде чем пытаться осчастливить игроков, слепо реализуя все их «советы» :)
Вот решил какой-нибудь программист в этот момент найти работу. Разослал резюме со ссылкой на свой гитхаб с кучей крутых проектов. Работодатели в предвкушении пошли по ссылке… и ничего не увидели, ничего не оценили. Спасибо РКН, что делаете нашу жизнь лучше и проще.
Наглость михалкова поражает воображение. И обиднее всего, наверное, тем пользователям, которые в жизни не «потребляли» контент авторства тех правообладателей, которые поддерживают этот закон.
Кнопки уж очень напоминают таковые из Angry Birds.
Если не находите в себе задатки художника, то графику лучше делать минималистричную, но главное, стильную. Есть множество примеров хороших игр с примитивной графикой, на которую, тем не менее, очень приятно смотреть.
Нет, не поэтому. В С описание функции f() говорит о том, что в нее можно передать произвольное количество параметров. Если надо сказать, что параметров действительно не должно быть, пишут f(void). В С++ это эквивалентные описания.
Лучше так не говорить, могут придраться. В С++ действительно есть доступ к стандартной библиотеке С, но нет полной поддержки его синтаксиса. Например, этот код не компилируется в С++, хотя верен в С:
По-моему, эта ошибка переоценена. Серьезно, очень много слышал и читал про нее, но на практике ни разу не видел реального примера, ни у себя в коде, ни у окружающих.
А если разбить эту функцию на 10 функций, очевидно завязанных друг на друга, то автоматически сразу нужно будет меньше помнить? Или код станет проще? По факту он может стать даже сложнее, ибо тесно связанный кусок кода просто ввиду алгоритма могут плохо разбиваться на отдельные функции, или у этих функций будет 10 параметров. Уж не говоря о том, что это однозначно усложнит трассировку кода. Вместо того, чтобы читать код сверху вниз, придется читать его мелкими отрывками (отдельными функциями) и вникать в суть их взаимодействия.
Во всем нужно знать меру. Километровые функции можно и нужно распиливать, но это не значит, что каждый шаг требует вынесения в отдельную функцию. Важно то, что каждая функция имеет имя, которое описывает выполняемое действие. При удачном подборе имен маленьких функций код большой функции превращается в набор простых предложений, который приятно читать. Никто не говорил, что процесс рефакторинга бывает легким, поэтому это ваша задача — избежать того, чтобы не было по 10 параметров там и тут. В конце концов, тема о комментариях, и если вам не нравится деление на функции, то можно было хотя бы сделать больше комментариев.
Не бывает такое в программирование, что большая функция — однозначно плохо, а 10 маленьких — однозначно хорошо и что-то улучшит. Излишнее стремление плодить мелкие функции — такой же вред, как отказаться от функций совсем.
В этом мире вообще почти ничего не бывает однозначным. Вы правильно пишете — крайности вредны, поэтому всегда важно чувство меры.
Функции нужны не для уменьшения строк кода (как некоторые видимо думают), а для разбиения кода на логические, независимые блоки, а также дедупликации этих блоков.
Это тесно связанные факторы. Хорошо разделенные, независимые и переиспользуемые блоки в конечном счете ведут к упрощению кода и препятствуют лавинообразному росту количества строк из-за копипасты.
Никто не предлагает дробить код на более мелкие части ради сокращения его размеров (действительно, кто эти «некоторые»?). Мотивация должна заключаться в хорошей самодокументированности результата.
clcf (718), e (556), of (684), tf (115) — в скобках указано количество раз, которое эти сокращения используются. Cокращения для часто используемых переменных, и не только, необходимы, поскольку это существенно уменьшает визуальный шум. Замените в 718-ти местах clcf на core_local_configuration, e на script_engine — и посмотрите как это будет выглядить. Ужасно будет.
Не впадайте в крайности. e достаточно заменить на engine, или вообще eng, и это уже будет лучше, потому что взгляд будет лучше различать, что это переменная, а не какая-нибудь цифра, к примеру. Однобуквенные переменные — вот что действительно ужасно. В следующий раз вы назовете переменную o, чтобы читатели офигевали, видя там и тут «нули».
Ну извините, если вы плохо знакомы с языком программирования на котором написан код, то разумеется он будет казаться плохо читабельным. А взять простого обывателя, так для него любой код будет малопонятной простыней из буковок и значков.
Давайте не будем делать странные выводы о владении языком. Я достаточно хорошо знаю язык, и, если на то пошло, вы меня пока не убедили, что знаете его лучше меня. Но знание языка тут не при чем. Язык — это способ описать алгоритм. Способность записать его в как можно более понятной человеку форме — хороший навык, в то время как лапша в коде говорит о каше в голове. Неужели у вас не было такого, что одна книга читается легко и приятно, а другая идет тяжелее? В обеих слова-то одни и те же, и по вашей логике, если человеку трудно читать вторую книгу, значит он плохо знаком с русским языком.
С вашим доводом в пользу комментария к непонятному короткому куску кода я не спорю, а вот критерий не такой уж и странный. Он довольно известный, и его легко обосновать. Когда человек не видит всю функцию целиком, ему приходится помнить скрытый в данный момент кусок кода, чтобы сложилась полная картина происходящего. Чем труднее его запомнить, тем больше времени тратится на чтение и понимание. И без того приходится помнить структуру программы в целом, а вы еще усложняете задачу.
Надо отметить, что названия переменных в духе clcf, e, of, tf и многочисленные goto в вашем коде также не способствуют легкому восприятию. Еще накладывается, что переменные, несущие один и тот же смысл, иногда называются по-разному. Например:
ngx_http_core_loc_conf_t *clcf;
// vs
ngx_http_core_loc_conf_t *pclcf;
Промотав на конец 100-строчного метода, в начале которого объявлены переменные, мне уже требуется усилие, чтобы помнить тип каждой из них.
В принципе, почти весь код на С, который я видел, мало отличается от вашего, разве что длиной функций. Думаю, это считается нормальным среди С программистов так писать, но читабельным от этого код не становится.
Кстати, если взять процент людей, которые начали читать Войну и Мир и дочитали до конца, то можно сказать, что книга действительно нечитабельна :)
И вывод такой: пользователь не знает, чего хочет, пока не увидит, что получил. Поэтому лучше десять раз подумать, прежде чем пытаться осчастливить игроков, слепо реализуя все их «советы» :)
Если не находите в себе задатки художника, то графику лучше делать минималистричную, но главное, стильную. Есть множество примеров хороших игр с примитивной графикой, на которую, тем не менее, очень приятно смотреть.
f()говорит о том, что в нее можно передать произвольное количество параметров. Если надо сказать, что параметров действительно не должно быть, пишутf(void). В С++ это эквивалентные описания.Лучше так не говорить, могут придраться. В С++ действительно есть доступ к стандартной библиотеке С, но нет полной поддержки его синтаксиса. Например, этот код не компилируется в С++, хотя верен в С:
Есть и другие примеры.
Во всем нужно знать меру. Километровые функции можно и нужно распиливать, но это не значит, что каждый шаг требует вынесения в отдельную функцию. Важно то, что каждая функция имеет имя, которое описывает выполняемое действие. При удачном подборе имен маленьких функций код большой функции превращается в набор простых предложений, который приятно читать. Никто не говорил, что процесс рефакторинга бывает легким, поэтому это ваша задача — избежать того, чтобы не было по 10 параметров там и тут. В конце концов, тема о комментариях, и если вам не нравится деление на функции, то можно было хотя бы сделать больше комментариев.
В этом мире вообще почти ничего не бывает однозначным. Вы правильно пишете — крайности вредны, поэтому всегда важно чувство меры.
Это тесно связанные факторы. Хорошо разделенные, независимые и переиспользуемые блоки в конечном счете ведут к упрощению кода и препятствуют лавинообразному росту количества строк из-за копипасты.
Никто не предлагает дробить код на более мелкие части ради сокращения его размеров (действительно, кто эти «некоторые»?). Мотивация должна заключаться в хорошей самодокументированности результата.
Не впадайте в крайности.
eдостаточно заменить наengine, или вообщеeng, и это уже будет лучше, потому что взгляд будет лучше различать, что это переменная, а не какая-нибудь цифра, к примеру. Однобуквенные переменные — вот что действительно ужасно. В следующий раз вы назовете переменнуюo, чтобы читатели офигевали, видя там и тут «нули».Давайте не будем делать странные выводы о владении языком. Я достаточно хорошо знаю язык, и, если на то пошло, вы меня пока не убедили, что знаете его лучше меня. Но знание языка тут не при чем. Язык — это способ описать алгоритм. Способность записать его в как можно более понятной человеку форме — хороший навык, в то время как лапша в коде говорит о каше в голове. Неужели у вас не было такого, что одна книга читается легко и приятно, а другая идет тяжелее? В обеих слова-то одни и те же, и по вашей логике, если человеку трудно читать вторую книгу, значит он плохо знаком с русским языком.
Надо отметить, что названия переменных в духе
clcf,e,of,tfи многочисленныеgotoв вашем коде также не способствуют легкому восприятию. Еще накладывается, что переменные, несущие один и тот же смысл, иногда называются по-разному. Например:Промотав на конец 100-строчного метода, в начале которого объявлены переменные, мне уже требуется усилие, чтобы помнить тип каждой из них.
В принципе, почти весь код на С, который я видел, мало отличается от вашего, разве что длиной функций. Думаю, это считается нормальным среди С программистов так писать, но читабельным от этого код не становится.
Кстати, если взять процент людей, которые начали читать Войну и Мир и дочитали до конца, то можно сказать, что книга действительно нечитабельна :)