История изменений
Исправление soomrack, (текущая версия) :
На мой взгляд такой код сложнее, если без привязки к задаче. Так то задача такая, что и в одну строчку можно написать выражение и не заморачиваться.
Мое, исключительно субъективное, мнение:
- Надо делать код четко под постановку задачи, не надо расширять ее самостоятельно.
Поэтому не нужно добавлять шаблоны, когда сказано, что входные значения это целые числа от 1 до 3000. (этот шаблон привел к тому, что этот код возможно придется засовывать в заголовочный файл, вместо того, чтобы отдавать в скомпиленной библиотеке).
Поэтому не нужно следить за выходом за разрядность. (а есть 100% уверенность, что при делении на 2 и превращении числа в float не добавится 1 в далеких дробных разрядах?).
- Вывод и ввод лучше отделять от основной логики вынося в отдельные функции, т.к. они могут зависеть от кучи факторов. (Я ввод не вынес).
В этом ответе требуемого вывода просто нет. Решение незаконченное.
- Чем тупее код, тем он понятней, идеально если он просто следует словестному решению задачи.
В данном случае это проверка на существование треугольника, которая заключается в том, что не должно быть стороны, которая больше суммы других. Ну так это три сравнения, соотв. я их и сделал. Они идут вначале функции, т.е. там, где обычно ставится проверка входных данных, клише.
Проверка того, что треугольник прямоугольный это опять же, проверка того, то квадрат одной стороны равен сумме квадратов двух других. Это опять же всего три варианта. Я их прямо и написал.
Каждая проверка, если успешна, вызывает функцию, которая делает то, что сказано в постановке задачи для этого результата и завершает тест.
Мой код с т.з. дерева принятия решений очень простой. Ну и как мелочь, но полезная мелочь, я даже не меняю значения переменных, что тоже добавляет прозрачности коду.
Про названия функций и переменных… Ну представьте, что в последней строчке есть опечатка, где-нибудь в середине вместо b стоит с, почти рядом на клавиатуре, можно и опечататься. Это же будет незаметно при беглом взгляде. А если в моем коде, вместо square будет написано length, то даже при беглом взгляде будет видна ошибка (так оно и было).
Исходная версия soomrack, :
На мой взгляд такой код сложнее, если без привязки к задаче. Так то задача такая, что и в одну строчку можно написать выражение и не заморачиваться.
Мое, исключительно субъективное, мнение:
- Надо делать код четко под постановку задачи, не надо расширять ее самостоятельно.
Поэтому не нужно добавлять шаблоны, когда сказано, что входные значения это целые числа от 1 до 3000. (этот шаблон привел к тому, что этот код возможно придется засовывать в заголовочный файл, вместо того, чтобы отдавать в скомпиленной библиотеке).
Поэтому не нужно следить за выходом за разрядность. (а есть 100% уверенность, что при делении на 2 и превращении числа в float не добавится 1 в далеких дробных разрядах?).
- Вывод и ввод лучше отделять от основной логики вынося в отдельные функции, т.к. они могут зависеть от кучи факторов. (Я ввод не вынес).
В этом ответе требуемого вывода просто нет. Решение незаконченное.
- Чем тупее код, тем он понятней, идеально если он просто следует словестному решению задачи.
В данном случае это проверка на существование треугольника, которая заключается в том, что не должно быть стороны, которая больше суммы других. Ну так это три сравнения, соотв. я их и сделал. Они идут вначале функции, т.е. там, где обычно ставится проверка входных данных, клише.
Проверка того, что треугольник прямоугольный это опять же, проверка того, то квадрат одной стороны равен сумме квадратов двух других. Это опять же всего три варианта. Я их прямо и написал.
Каждая проверка, если успешна, вызывает функцию, которая делает то, что сказано в постановке задачи для этого результата.
Мой код с т.з. дерева принятия решений очень простой. Ну и как мелочь, но полезная мелочь, я даже не меняю значения переменных, что тоже добавляет прозрачности коду.
Про названия функций и переменных… Ну представьте, что в последней строчке есть опечатка, где-нибудь в середине вместо b стоит с, почти рядом на клавиатуре, можно и опечататься. Это же будет незаметно при беглом взгляде. А если в моем коде, вместо square будет написано length, то даже при беглом взгляде будет видна ошибка (так оно и было).