AA
Если короче, то вы так условия прописали, что ничего не попадает)
То есть у вас:
1) либо 8, тогда первый puts.
2) либо равно либо больше 8, тогда второй puts.
3) всё остальное валится в else
Size: a a a
2019 August 01
AA
ДБ
choice <= -1 вот это удалить
ДБ
Либо elsif
ДБ
Но без else плохо писать код
2019 August 02
АК
Доброе утро всем! В видео уроках ребята говорят о том, что решение задачи в программирование может иметь несколько путей. И я уже в этом убедился, т.к. мои решения не совпадают с решением ребят, но при этом поставленная цель достигается. Возникает вопрос, если путей решения задач несколько, то как отличить говнокод от кода. Стараюсь писать код таким образом, чтобы строк было не много, и если вдруг что-то нужно будет менять или добавлять, то правок делалось не много. Я на верном пути обучения товарищи? :)
GG
Доброе утро всем! В видео уроках ребята говорят о том, что решение задачи в программирование может иметь несколько путей. И я уже в этом убедился, т.к. мои решения не совпадают с решением ребят, но при этом поставленная цель достигается. Возникает вопрос, если путей решения задач несколько, то как отличить говнокод от кода. Стараюсь писать код таким образом, чтобы строк было не много, и если вдруг что-то нужно будет менять или добавлять, то правок делалось не много. Я на верном пути обучения товарищи? :)
Найти ментора)
SS
Доброе утро всем! В видео уроках ребята говорят о том, что решение задачи в программирование может иметь несколько путей. И я уже в этом убедился, т.к. мои решения не совпадают с решением ребят, но при этом поставленная цель достигается. Возникает вопрос, если путей решения задач несколько, то как отличить говнокод от кода. Стараюсь писать код таким образом, чтобы строк было не много, и если вдруг что-то нужно будет менять или добавлять, то правок делалось не много. Я на верном пути обучения товарищи? :)
АК
Найти ментора)
Спасибо!
DM
Спасибо!
https://rubystyle.guide вот еще маст рид
ЮМ
Привет, ищу ROR разраба на фулл тайм, удаленно, с хорошим английским. ЗП от 100+к
ЮМ
Требования:
* Ruby on Rails 4 (API)
* Ruby 2
* Writing SQL queries (Postgresql)
* Unit testing using rspec
* Git
* Ruby on Rails 4 (API)
* Ruby 2
* Writing SQL queries (Postgresql)
* Unit testing using rspec
* Git
АЯ
Доброе утро всем! В видео уроках ребята говорят о том, что решение задачи в программирование может иметь несколько путей. И я уже в этом убедился, т.к. мои решения не совпадают с решением ребят, но при этом поставленная цель достигается. Возникает вопрос, если путей решения задач несколько, то как отличить говнокод от кода. Стараюсь писать код таким образом, чтобы строк было не много, и если вдруг что-то нужно будет менять или добавлять, то правок делалось не много. Я на верном пути обучения товарищи? :)
Сокращения тоже могут привести к говнокоду.
Хороший код от говнокода отличается тем, что читается без комментариев или почти без комментариев даже если написали его не вы или прошёл месяц, а вы всё ещё можете понять, что вы тут такое накодили и как это можно изменить, если вдруг нужно. Обычно, через месяц-два к своему коду возвращаются как раз за этим, либо чтобы что-то дёрнуть оттуда. Поэтому отсюда вытекает несколько следствий:
- переменные и методы должны иметь осмысленные имена
- переменные должны своим существованием помогать пониманию кода (например, в руби, как и в многих других ЯП, можно вполне себе писать вызов метода в качестве аргумента другого метода, но не всегда это выглядит понятно и читаемо)
- методы должны совсем не изменять глобальных переменных, или делать это по минимуму и явным образом
- методы должны быть максимально короткими и выполнять строго одну задачу
- комментарии нужны, но превращать код в один большой комментарий с парой строчек кода тоже не стоит (если, конечно, это не код, по которому что-то объясняется совсем новичку)
- комментировать лучше неочевидные решения или какие-то спорные моменты, которые пришлось вставить в код, но не факт, что это лучшее решение
Все это я прочитал в какой-то статье, как-то запомнил и как-то пересказал. Сам я стремлюсь кодить именно в таком духе, и это все же не всегда приводит к тому, что мне не стыдно за то дерьмо, что я писал в прошлом году. Но это не означает, что мне стыдно за всё, что я писал в прошлом году. Иногда, всё же, там находится что-то полезное 😊
Хороший код от говнокода отличается тем, что читается без комментариев или почти без комментариев даже если написали его не вы или прошёл месяц, а вы всё ещё можете понять, что вы тут такое накодили и как это можно изменить, если вдруг нужно. Обычно, через месяц-два к своему коду возвращаются как раз за этим, либо чтобы что-то дёрнуть оттуда. Поэтому отсюда вытекает несколько следствий:
- переменные и методы должны иметь осмысленные имена
- переменные должны своим существованием помогать пониманию кода (например, в руби, как и в многих других ЯП, можно вполне себе писать вызов метода в качестве аргумента другого метода, но не всегда это выглядит понятно и читаемо)
- методы должны совсем не изменять глобальных переменных, или делать это по минимуму и явным образом
- методы должны быть максимально короткими и выполнять строго одну задачу
- комментарии нужны, но превращать код в один большой комментарий с парой строчек кода тоже не стоит (если, конечно, это не код, по которому что-то объясняется совсем новичку)
- комментировать лучше неочевидные решения или какие-то спорные моменты, которые пришлось вставить в код, но не факт, что это лучшее решение
Все это я прочитал в какой-то статье, как-то запомнил и как-то пересказал. Сам я стремлюсь кодить именно в таком духе, и это все же не всегда приводит к тому, что мне не стыдно за то дерьмо, что я писал в прошлом году. Но это не означает, что мне стыдно за всё, что я писал в прошлом году. Иногда, всё же, там находится что-то полезное 😊
АК
Сокращения тоже могут привести к говнокоду.
Хороший код от говнокода отличается тем, что читается без комментариев или почти без комментариев даже если написали его не вы или прошёл месяц, а вы всё ещё можете понять, что вы тут такое накодили и как это можно изменить, если вдруг нужно. Обычно, через месяц-два к своему коду возвращаются как раз за этим, либо чтобы что-то дёрнуть оттуда. Поэтому отсюда вытекает несколько следствий:
- переменные и методы должны иметь осмысленные имена
- переменные должны своим существованием помогать пониманию кода (например, в руби, как и в многих других ЯП, можно вполне себе писать вызов метода в качестве аргумента другого метода, но не всегда это выглядит понятно и читаемо)
- методы должны совсем не изменять глобальных переменных, или делать это по минимуму и явным образом
- методы должны быть максимально короткими и выполнять строго одну задачу
- комментарии нужны, но превращать код в один большой комментарий с парой строчек кода тоже не стоит (если, конечно, это не код, по которому что-то объясняется совсем новичку)
- комментировать лучше неочевидные решения или какие-то спорные моменты, которые пришлось вставить в код, но не факт, что это лучшее решение
Все это я прочитал в какой-то статье, как-то запомнил и как-то пересказал. Сам я стремлюсь кодить именно в таком духе, и это все же не всегда приводит к тому, что мне не стыдно за то дерьмо, что я писал в прошлом году. Но это не означает, что мне стыдно за всё, что я писал в прошлом году. Иногда, всё же, там находится что-то полезное 😊
Хороший код от говнокода отличается тем, что читается без комментариев или почти без комментариев даже если написали его не вы или прошёл месяц, а вы всё ещё можете понять, что вы тут такое накодили и как это можно изменить, если вдруг нужно. Обычно, через месяц-два к своему коду возвращаются как раз за этим, либо чтобы что-то дёрнуть оттуда. Поэтому отсюда вытекает несколько следствий:
- переменные и методы должны иметь осмысленные имена
- переменные должны своим существованием помогать пониманию кода (например, в руби, как и в многих других ЯП, можно вполне себе писать вызов метода в качестве аргумента другого метода, но не всегда это выглядит понятно и читаемо)
- методы должны совсем не изменять глобальных переменных, или делать это по минимуму и явным образом
- методы должны быть максимально короткими и выполнять строго одну задачу
- комментарии нужны, но превращать код в один большой комментарий с парой строчек кода тоже не стоит (если, конечно, это не код, по которому что-то объясняется совсем новичку)
- комментировать лучше неочевидные решения или какие-то спорные моменты, которые пришлось вставить в код, но не факт, что это лучшее решение
Все это я прочитал в какой-то статье, как-то запомнил и как-то пересказал. Сам я стремлюсь кодить именно в таком духе, и это все же не всегда приводит к тому, что мне не стыдно за то дерьмо, что я писал в прошлом году. Но это не означает, что мне стыдно за всё, что я писал в прошлом году. Иногда, всё же, там находится что-то полезное 😊
Спасибо за развернутый ответ :) возьму на заметку :)
АЯ
народ, а есть тут линуксоиды на i3wm? вопрос есть по настройке внешнего вида рубимайна под i3wm
M
Доброе утро всем! В видео уроках ребята говорят о том, что решение задачи в программирование может иметь несколько путей. И я уже в этом убедился, т.к. мои решения не совпадают с решением ребят, но при этом поставленная цель достигается. Возникает вопрос, если путей решения задач несколько, то как отличить говнокод от кода. Стараюсь писать код таким образом, чтобы строк было не много, и если вдруг что-то нужно будет менять или добавлять, то правок делалось не много. Я на верном пути обучения товарищи? :)
Не думайте об этом вообще. Думайте о максимальном качестве и надежности работы программ.
Это можно самому со стороны оценить. Можно собственную прогу потестить, сломать и пр.
А собственный код оценить на красоту если вы новичок — нельзя и на первых порах не сильно нужно.
Это можно самому со стороны оценить. Можно собственную прогу потестить, сломать и пр.
А собственный код оценить на красоту если вы новичок — нельзя и на первых порах не сильно нужно.
M
Сокращения тоже могут привести к говнокоду.
Хороший код от говнокода отличается тем, что читается без комментариев или почти без комментариев даже если написали его не вы или прошёл месяц, а вы всё ещё можете понять, что вы тут такое накодили и как это можно изменить, если вдруг нужно. Обычно, через месяц-два к своему коду возвращаются как раз за этим, либо чтобы что-то дёрнуть оттуда. Поэтому отсюда вытекает несколько следствий:
- переменные и методы должны иметь осмысленные имена
- переменные должны своим существованием помогать пониманию кода (например, в руби, как и в многих других ЯП, можно вполне себе писать вызов метода в качестве аргумента другого метода, но не всегда это выглядит понятно и читаемо)
- методы должны совсем не изменять глобальных переменных, или делать это по минимуму и явным образом
- методы должны быть максимально короткими и выполнять строго одну задачу
- комментарии нужны, но превращать код в один большой комментарий с парой строчек кода тоже не стоит (если, конечно, это не код, по которому что-то объясняется совсем новичку)
- комментировать лучше неочевидные решения или какие-то спорные моменты, которые пришлось вставить в код, но не факт, что это лучшее решение
Все это я прочитал в какой-то статье, как-то запомнил и как-то пересказал. Сам я стремлюсь кодить именно в таком духе, и это все же не всегда приводит к тому, что мне не стыдно за то дерьмо, что я писал в прошлом году. Но это не означает, что мне стыдно за всё, что я писал в прошлом году. Иногда, всё же, там находится что-то полезное 😊
Хороший код от говнокода отличается тем, что читается без комментариев или почти без комментариев даже если написали его не вы или прошёл месяц, а вы всё ещё можете понять, что вы тут такое накодили и как это можно изменить, если вдруг нужно. Обычно, через месяц-два к своему коду возвращаются как раз за этим, либо чтобы что-то дёрнуть оттуда. Поэтому отсюда вытекает несколько следствий:
- переменные и методы должны иметь осмысленные имена
- переменные должны своим существованием помогать пониманию кода (например, в руби, как и в многих других ЯП, можно вполне себе писать вызов метода в качестве аргумента другого метода, но не всегда это выглядит понятно и читаемо)
- методы должны совсем не изменять глобальных переменных, или делать это по минимуму и явным образом
- методы должны быть максимально короткими и выполнять строго одну задачу
- комментарии нужны, но превращать код в один большой комментарий с парой строчек кода тоже не стоит (если, конечно, это не код, по которому что-то объясняется совсем новичку)
- комментировать лучше неочевидные решения или какие-то спорные моменты, которые пришлось вставить в код, но не факт, что это лучшее решение
Все это я прочитал в какой-то статье, как-то запомнил и как-то пересказал. Сам я стремлюсь кодить именно в таком духе, и это все же не всегда приводит к тому, что мне не стыдно за то дерьмо, что я писал в прошлом году. Но это не означает, что мне стыдно за всё, что я писал в прошлом году. Иногда, всё же, там находится что-то полезное 😊
Тоже годные рекомендации