Prośba o ocenę pierwszego projektu

0

Witam, chciałbym poprosić o ocenę i wskazówki co do projektu.

Projekt jest prostą aplikacją konsolową, która ma za zadanie konwertować różne jednostki na inne skale pomiarowe, wprowadziłem tam również funkcję ciągu Fibonacciego, pola figur i w obecnej sytuacji jestem w stanie dodać coś jeszcze, ponieważ "skonstruowałem" dość dobry system dodawania ficzerów, choć nie mnie oceniać :D

0
  1. Brak zabezpieczeń przed wpisywaniem bzdurnych danych.
  2. NIe wiadomo w jakim formacie wpisywać liczby. Wpisanie promienia 3,5 powoduje błąd a to w Polsce poprawny format.
  3. Tak samo poprawną liczbą jest 1 000 000.
  4. Brak powrotu do poprzedniego menu.
  5. Wpisanie pustej wartości powoduje błąd.
  6. Po wybraniu "Length Scales" znikają mi z ekranu pierwsze opcje widzę dopiero od 30 ... Nie każdy musi wiedzieć, że może przewinąć ekran do góry a nawet nie każda konsola ma taką możliwość.
  7. Z liczbami Fibonacciego w ogóle nie wiadomo o co chodzi.

To tak na sam początek.

Menu         
1.Temperature Scales
2.Weight Scales
3.Length Scales
4.Figure Areas
5.Fibonacci Numbers
6.Time Scales
Enter the category number you are interested in:4

You selected Figure Areas
1. Calculate a area of square
2. Calculate a area of rectangle
3. Calculate a area of parallelogram
4. Calculate a area of trapezoid
5. Calculate a area of circle
Enter the type of:5
Type length of circle radius
erwfsdfasd
Traceback (most recent call last):
  File "Z:/__PY/ConverterMenu.py", line 262, in <module>
    menu()
  File "Z:/__PY/ConverterMenu.py", line 109, in menu
    text()
  File "Z:/__PY/ConverterMenu.py", line 58, in figure_areas_category
    function()
  File "Z:\__PY\Core.py", line 982, in circle_area
    r = float(input())
ValueError: could not convert string to float: 'erwfsdfasd'

Process finished with exit code 1
0
  1. Naprawione
  2. Naprawione
  3. Naprawione
  4. Po co? Sekunda różnicy dla osób chcących wrócić do tego samego menu jest tak ważna? W dalszej perspektywie to jest irytujące, dlatego tego nie mam zamiaru implementować, choć nadal szanuje, iż ty preferowałbyś taką funkcję.
  5. Naprawione
  6. Teoretycznie problem śmieszny, lecz po chwili zastanowienia jest on realny.Tylko zastanawia mnie jedno,jaka konsola nie ma opcji przewijania tekstu? Jeżeli jakąś znasz to chętnie się zapoznam :D
  7. Tutaj dość prozaiczny błąd, print w złym miejscu :D

Zaktualizowany kod jest w załączniku

Dziękuje za odpowiedź
Pozdrawiam

2

Jak napisał @katakrowa, a Fibonacci to WTF? Poza tym:
Wrzuć kod na github, czy coklwiek.
Dodaj dokumentację (np. w README).
Dodaj licencję.
I testy, unit testy w tym przypadku, skąd ktokolwiek, nie wyłączając Ciebie, ma wiedzieć czy to działa. Wiesz, projekt, to już ma być coś, w zamyśle, coś co ktos może użyć.

0

Zgodnie z tym co koledzy wyżej napisali. Umieść kod na GIT ( np. bitbucket.org ).

ad 4. A po to, że skoro jest menu to dobra praktyka mówi, że trzeba zaimplementować powrót do opcji wyżej. Zrobiłeś program z menu to daj użytkownikowi się po nim poruszać. Mogłeś zrezygnować z menu i wywoływać wybrane opcje z parametru programu wówczas bym się nie czepiał a w tej chwili to duża niedogodność a w mojej ocenie błąd.

ad. Jeżeli jakąś znasz to chętnie się zapoznam :D

Prawie każda konsola ma możliwość ustawienia bufora zapamiętywanych wierszy historycznych na 0 i wyobraź sobie, że są tacy co z tej opcji korzystają nie tylko dla zabawy. Dla przykładu możesz sprawdzić zwykłą konsolę w Windows => zwykły cmd zakładka Układ=>Rozmiar buforu ekranu. Nie wspomnę o tym, że pracując na różnych konsolach zdalnych np. poprzez KVM możesz nie mieć możliwości przewijania. Gdyby było inaczej nie wymyślano by stronicowania, komendy MORE i wielu innych rozwiązań te jednak mają zastosowanie głównie przy czytaniu a Twój program dodatkowo wprowadza interakcję z użytkownikiem więc dobrze byłoby mieć możliwość przeglądania wszystkich opcji.

1

No i jeszcze uwaga dotycząca samego kodu, który może działa ale jest napisany całkowicie niezgodnie ze sztuką i jeśli to projekt "na zaliczenie" to chyba może być większy kłopot niż wcześniej wskazane błędy.
W pliku Core.py wystarczyłyby 4 funkcje których cały kod zmieściłby się na jednym ekranie może dwóch. Współczynniki i nazwy jednostek należałoby wywalić do tablicy z konfiguracją. W menu wtedy też nie musiałbyś mieć tylu opcji lub też menu mogłoby wygenerować się automatycznie ... No może przeliczanie pow. figur dałbym osobno ale przeliczanie wszystkich jednostek to jedna funkcja.

1

W pliku Core.py wystarczyłyby 4 funkcje których cały kod zmieściłby się na jednym ekranie może dwóch. Współczynniki i nazwy jednostek należałoby wywalić do tablicy z konfiguracją. W menu wtedy też nie musiałbyś mieć tylu opcji lub też menu mogłoby wygenerować się automatycznie ...

Otóż to. Tyle funkcji do każdej możliwej jednostki to jeden wielki WTF. A przecież większość tych jednostek opiera się na prostych zasadach (np. metr to 100 centymetrów), czemu w pamięci (albo z kalkulatorem) można to bez problemu policzyć, wiedząc, że np. metr to 100 centymetrów, a kilogram to 1000 gramów, a w kodzie napisałeś tak, jakby każdy przypadek był inny (a tu warto pomyśleć bardziej tak, żeby objąć jedną abstrakcją więcej przypadków naraz). Tak samo w każdej funkcji importujesz ConvertMenu (co też jest bez sensu - wystarczyłoby raz zaimportować na początku pliku ConvertMenu).

Tylko, że to ConvertMenu to do niczego ci nie potrzebne, a nawet nie powinieneś tego importować - to ConvertMenu przecież używa Core i wywołuje jej funkcje, więc Core(które gra tu rolę biblioteki narzędziowej) w ogóle nie powinno wiedzieć nic o ConvertMenu. Po co robić cykliczne zależności?

No i tak - twoje funkcje nazywają się tak, jakby służyły do konwersji jednostek (kilogram_to_gram) - ale w rzeczywistości jakaś większa magia się dzieje - każda funkcja u ciebie nie tylko przelicza jednostki, ale też w każdej funkcji robisz print oraz input oraz wyświetlasz jakieś menu (ConverterMenu.menu()).


def feet_to_inch():
    feet = float(input())
    inch = feet * 12.000
    print(inch)
    input("\nClick enter to proceed")
    import ConverterMenu
    ConverterMenu.menu()

To sprawia, że twoje funkcje są nieelastyczne i się nie przydadzą do niczego poza jednym konkretnym zastosowaniem.

Bo narobiłeś się, porobiłeś te konwertery. I załóżmy, że chcesz wykorzystać ten kod w jakimś innym projekcie, więc importujesz ten plik Core.py w jakimś innym kompletnie projekcie, w którym robisz coś, co wymaga konwersji jednostek. I co? I figa. Nie wykorzystasz tego, bo każda funkcja robi jakieś print, jakieś menu, nawet jeśli tego nie potrzebujesz w danym momencie, zaśmieca ci output konsoli (a to inny projekt, więc nie będziesz chciał, żeby ci printowało do konsoli, tylko chcesz skonwertować jednostkę). Na dodatek każda funkcja bierze wartość ze standardowego wejścia, a przecież w innym projekcie możliwe, że wartości będą zakodowane w skrypcie, więc ten kod będzie miał zerową użyteczność w innym zastosowaniu niż to, które masz aktualnie.

Lepszy sposób pisania to taki, w którym funkcja przyjmuje dane w argumentach i zwraca wartość:

def feet_to_inch(feet):
    return feet * 12.000

Prawda, że prościej?

Skąd będą dane brane, i co będzie potem robione z danymi (np. czy będą printowane, zapamiętane do zmiennej czy cokolwiek innego), to już nie powinno funkcji obchodzić. Funkcje konwertujące jednostki powinny konwertować jednostki, a nie robić tysiąc rzeczy naraz.

3 
os.system("cls")

Istnieją inne systemy niż Windows.

1 użytkowników online, w tym zalogowanych: 0, gości: 1