Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Antos Shakhbazau #55

Open
wants to merge 27 commits into
base: master
Choose a base branch
from
Open

Conversation

Antossh
Copy link

@Antossh Antossh commented Jun 6, 2019

No description provided.

@Antossh Antossh closed this Jun 6, 2019
@Antossh Antossh reopened this Jun 6, 2019
@Antossh Antossh changed the title [WIP] Antos 2 Antos Shakhbazau Jun 6, 2019
@@ -0,0 +1,384 @@
import re
from argparse import ArgumentParser
from math import *
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

импорт через звездочку -- это зло

Copy link
Author

@Antossh Antossh Jun 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alexei, спасибо за review!
то есть лучше указывать весь список функций из math? их там довольно много. у меня раньше было import math, стоило так оставить?

from math import *

""" global variables for tolerance to be used if isclose function is called """
r = 1e-09
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Не понимаю что это и для чего это

Copy link
Author

@Antossh Antossh Jun 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

в math есть функция isclose. она принимает, кроме х и у, еще два параметра - relative tolerance и absolute minimum tolerance. сначала указаны их default values (1е-09 и 0.0). Если юзер указывает свои, а не дефолтные, то при парсинге я их забираю в глобальные переменные, а при вызове функции применяю. там в докстринге написано.

i, k, j, m - это локальные переменные, они хранят индекс элемента буквально пару строк. их действительно нужно как-то значимо называть?
в длинных функциях я старался объяснить внутреннюю логику как докстрингом, так и внутренними #-комментами.
коммиты типа "Delete Attempt zwei" - это просто я не умел пользоваться гитхабом, увы. они не несут смысловой нагрузки.

a = 0.0

""" left-associated functions from math """
Left_func = [sin, cos, tan, asin, acos, atan, asinh, acosh, atanh, sinh, cosh, tanh, exp, abs, round,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Названия функций можно получить динамически

Copy link
Author

@Antossh Antossh Jun 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@AlexeiBuzuma
Copy link
Collaborator

AlexeiBuzuma commented Jun 9, 2019

  1. Сообщения коммитов в гите должны нести какой-то смысл изменения, которое было сделано в этом коммите. Сообщение Delete Attempt zwei не несет особого смысла.
  2. Для такого решения скорее всего должна существовать только одна (максимум две-три, и то с натяжкой) точка выхода из программы. В данном случае exit вызывается в 28 местах
  3. i, k, j, m -- все это магические переменные, которые не несут никакого смысла. Название переменной должно четко описывать ее задачу.
  4. Иногда встречаются магические числа, понять, что они значат крайне сложно. например if ... and precedences_dic[operator1] == 3.9
  5. В данном решении глобальные переменные используются на запись, что очень вредит читаемости и дает почтву для огромного количества багов. Использование ООП в данном случае упростило бы задачу.
  6. Зачастую функции очень тяжело читать из-за их размера и количества логики, которая содержиться в этих функциях. Советую в будущем больше внимание уделять на декомпозицию. Много маленьких функций намного лучше, чем несколько больших. Возможно использование ООП помогло бы сделать код более читаемым.
  7. Советую много практиковаться и постоянно писать код. Есть много ресурсов, где можно найти большое количество небольших и интересных заданий. Например https://www.codewars.com/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants