История изменений

в таких задачах захаркоженных параметров быть не должно. Код должен 1:1 отвечать тому что записано на бумашке/доске, а там всегда стоят буковки а не какое то 0.05.

Ну нету у меня сейчас буковок, написал так. Были бы буковки поставил бы их, а точнее полноценно назвал бы переменные.

если Вы таки захотите оставить функции, то Вы упреиесь в передачу параметров. Глобальные переменные это общеизвкстеый антипаттерн.

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

таким образом мы неизбежно приходим либо к одной функции (максимально пррстое решение),

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

либо к классу (правильно решение на вырост)

А классы еще не знают, да и не нужен класс для одного параметра.

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

Будет несколько параметров – будет класс или структура, если это С. Соотв. когда я обучаю студентов, то так и происходит, как только эта схема написания кода перестает отвечать сложности задачи, и это все студенты прочувствуют, видя как код превращается в хаос, я рассказывают про то, какие средства есть чтобы сделать код простым для этой новой сложности. В данном случае это будет или структура (если Си) или класс (если С++).

Нет конечно. Бактерии размножаются как dx/dt = ax при безлимитных ресурсах. В этом случае бактерии не взаимодействуют друг с другом, тупо делятся раз в сколько то минут, откуда там квадрат?!

А, ну да. Переклинило что-то, от времени квадрат.

PS: поймите меня правильно, я не спорю, что паттерн модель это хорошо, что классы это хорошо, что неизменяемые параметры это хорошо. Я говорю о том, что простые вещи нужно делать просто и не нужно использовать сложные методы для простых задач, усложняя код. Кроме того, не все их знают, нельзя несколько лекций подряд рассказывать сложные вещи, а потом чтобы их реализовывали. Все должно быть постепенно. Каждый подход к написанию кода имеет свой лимит по сложности решаемой задачи и свой порог входа, и про это нельзя забывать. Приведенный пример это второе задание при обучении программированию (первое это запустить hello world из IDE), а вы сразу паттерны и классы хотите. Много из тех, кто используют код вообще ни паттернов, и даже ООП могут и не знать. Если быть чуть более корректным, то мое второе задание это моделирование актива, т.е. что выгодней взять ипотеку или копить в банке, соотв. там я предупреждаю, что будут разные события, типа кризиса и потери работы и нужно промоделировать разные варианты… Это хорошая задача, которая и интересна с практической т.з. и требует усложнения кода, т.е. довольно быстро приходится создавать структуры, но не прям сразу.

PSS: «ак только эта схема написания кода перестает отвечать сложности задачи, и это все студенты прочувствуют, видя как код превращается в хаос, я рассказывают про то, какие средства есть чтобы сделать код простым для этой новой сложности.» – с таким подходом то вы согласны?

в таких задачах захаркоженных параметров быть не должно. Код должен 1:1 отвечать тому что записано на бумашке/доске, а там всегда стоят буковки а не какое то 0.05.

Ну нету у меня сейчас буковок, написал так. Были бы буковки поставил бы их, а точнее полноценно назвал бы переменные.

если Вы таки захотите оставить функции, то Вы упреиесь в передачу параметров. Глобальные переменные это общеизвкстеый антипаттерн.

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

таким образом мы неизбежно приходим либо к одной функции (максимально пррстое решение),

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

либо к классу (правильно решение на вырост)

А классы еще не знают, да и не нужен класс для одного параметра.

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

Будет несколько параметров – будет класс или структура, если это С. Соотв. когда я обучаю студентов, то так и происходит, как только эта схема написания кода перестает отвечать сложности задачи, и это все студенты прочувствуют, видя как код превращается в хаос, я рассказывают про то, какие средства есть чтобы сделать код простым для этой новой сложности. В данном случае это будет или структура (если Си) или класс (если С++).

Нет конечно. Бактерии размножаются как dx/dt = ax при безлимитных ресурсах. В этом случае бактерии не взаимодействуют друг с другом, тупо делятся раз в сколько то минут, откуда там квадрат?!

А, ну да. Переклинило что-то, от времени квадрат.

PS: поймите меня правильно, я не спорю, что паттерн модель это хорошо, что классы это хорошо, что неизменяемые параметры это хорошо. Я говорю о том, что простые вещи нужно делать просто и не нужно использовать сложные методы для простых задач, усложняя код. Кроме того, не все их знают, нельзя несколько лекций подряд рассказывать сложные вещи, а потом чтобы их реализовывали. Все должно быть постепенно. Каждый подход к написанию кода имеет свой лимит по сложности решаемой задачи и свой порог входа, и про это нельзя забывать. Приведенный пример это второе задание при обучении программированию (первое это запустить hello world из IDE), а вы сразу паттерны и классы хотите. Много из тех, кто используют код вообще ни паттернов, и даже ООП могут и не знать. Если быть чуть более корректным, то мое второе задание это моделирование актива, т.е. что выгодней взять ипотеку или копить в банке, соотв. там я предупреждаю, что будут разные события, типа кризиса и потери работы и нужно промоделировать разные варианты… Это хорошая задача, которая и интересна с практической т.з. и требует усложнения кода, т.е. довольно быстро приходится создавать структуры, но не прям сразу.

в таких задачах захаркоженных параметров быть не должно. Код должен 1:1 отвечать тому что записано на бумашке/доске, а там всегда стоят буковки а не какое то 0.05.

Ну нету у меня сейчас буковок, написал так. Были бы буковки поставил бы их, а точнее полноценно назвал бы переменные.

если Вы таки захотите оставить функции, то Вы упреиесь в передачу параметров. Глобальные переменные это общеизвкстеый антипаттерн.

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

таким образом мы неизбежно приходим либо к одной функции (максимально пррстое решение),

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

либо к классу (правильно решение на вырост)

А классы еще не знают, да и не нужен класс для одного параметра.

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

Будет несколько параметров – будет класс или структура, если это С. Соотв. когда я обучаю студентов, то так и происходит, как только эта схема написания кода перестает отвечать сложности задачи, и это все студенты прочувствуют, видя как код превращается в хаос, я рассказывают про то, какие средства есть чтобы сделать код простым для этой новой сложности. В данном случае это будет или структура (если Си) или класс (если С++).

Нет конечно. Бактерии размножаются как dx/dt = ax при безлимитных ресурсах. В этом случае бактерии не взаимодействуют друг с другом, тупо делятся раз в сколько то минут, откуда там квадрат?!

А, ну да. Переклинило что-то, от времени квадрат.

в таких задачах захаркоженных параметров быть не должно. Код должен 1:1 отвечать тому что записано на бумашке/доске, а там всегда стоят буковки а не какое то 0.05.

Ну нету у меня сейчас буковок, написал так. Были бы буковки поставил бы их, а точнее полноценно назвал бы переменные.

если Вы таки захотите оставить функции, то Вы упреиесь в передачу параметров. Глобальные переменные это общеизвкстеый антипаттерн.

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

таким образом мы неизбежно приходим либо к одной функции (максимально пррстое решение),

плохое решение, при небольшом усложнении кода функцию начнет распирать от комментов и пр.

либо к классу (правильно решение на вырост)

А классы еще не знают, да и не нужен класс для одного параметра.

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

Будет несколько параметров – будет класс или структура, если это С. Соотв. когда я обучаю студентов, то так и происходит, как только эта схема написания кода перестает отвечать сложности задачи, и это все студенты прочувствуют, видя как код превращается в хаос, я рассказывают про то, какие средства есть чтобы сделать код простым для этой новой сложности. В данном случае это будет или структура (если Си) или класс (если С++).

Нет конечно. Бактерии размножаются как dx/dt = ax при безлимитных ресурсах. В этом случае бактерии не взаимодействуют друг с другом, тупо делятся раз в сколько то минут, откуда там квадрат?!

А, ну да. Переклинило что-то, от времени квадрат.