Zamykanie się programu w rozszerzonym mini projekcie z bankomatu. Dlaczego ?

pytanie zadane 24 sierpnia 2016 w C i C++ przez PodBot Nowicjusz (160 p.)
zmienione kategorie 24 sierpnia 2016 przez Arkadiusz Waluk

Hej,

Zaczynam dopiero kodowac w C++. Zrobiłem sobie rozoszerzenie projektu "bankomat" z tutoriala na YT. Chciałem aby program oprocz sprawdzenia poprawnosci numeru PIN wyświetlał ilość pozostałych prób po nieprawidłowo wpisanym kodzie. Dlatego oprocz zastosowanego if musiałem dodać także pętle. Niestety po napisaniu kodu i włączeniu programu następuje crash po wpisaniu byle jakiej cyfry. Czy mógłby mnie ktoś naprowadzićgdzie robie błąd.

Pozdrawiam

#include <iostream>

using namespace std;

string PIN;
int proby = 3;


int main()
{
    cout << "witaj w naszym banku" << endl;
    cout << "Podaj numer PIN:";

while (proby==0)
{
 cin >>PIN;

    if (PIN=="1279")
    {
        cout << "PIN poprawny";
    break;
    }
   else
   {
       proby = proby-1;
        cout << "PIN niepoprawny pozostalo prob: "<< proby ;
    }

2
}

    return 0;
}

6 odpowiedzi

odpowiedź 24 sierpnia 2016 przez draghan VIP (106,230 p.)

Chyba Ci się dwójka niepotrzebnie zaplątała w 29. linijce. ;)

Problem polega na błędnym warunku pętli. Co ciekawe, nie następuje 'crash', ani nawet nie ma szansy na wprowadzenie liczby.

Ty napisałeś w kodzie, że pętla ma się wykonywać wtedy, kiedy proby == 0. Ale przecież już na samym początku nadajesz tej zmiennej wartość 3. ;) Popraw odrobinę warunek i będzie działać.

Staraj się nie definiować zmiennych globalnych oraz unikać deklaracji using namespace std;, jawnie klasyfikując wszystkie identyfikatory, np. std::cout.

Pokaż 10 poprzednich komentarzy

komentarz 25 sierpnia 2016 przez draghan VIP (106,230 p.)

Wszystkie słowa kluczowe języka są angielskie, a wraz z angielskimi identyfikatorami komponują zgrabną i schludną całość.

To akurat nie jest już żaden argument.

Tak myślałem. Ale odnieś się może do pozostałej części komentarza. :)

Dodam tylko że takich różnych widzimisię jest więcej. Ciekawe jak w zespole pisać klamry... Tam też jest niezła zagwozdka, co programista to pisze to inaczej... Myślę że to większy problem niż zmienne.

Dlatego każdy zespół powinien mieć code style guide - dokument określający zasady formatowania źródeł.

Poza tym na spoju "autorytety" twierdzą że np lepiej używać scanf zamiast cin bo jest o miliardowe części sekundy szybszy... Albo że używanie << endl; jest nieprawidłowe i powinno się pisać "\n"

No i mają rację, przynajmniej w wąskim zakresie. std::endl to nie to samo, co escape-sequence '\n', zaś implementacja strumieni C++ jest rzeczywiście nieco wolniejsza niż funkcje z cstdio. To MA znaczenie na SPOJu. ;)

A ja myślę że to są tak nieistotne pierdoły że szkoda czasu na pisanie tego posta... Każdy sobie pisze jak mu się podoba. A jak pójdę do firmy X i będzie wymóg aby pisać scanf to po prostu tak będę pisał. Ale mówienie komuś że tak jest "bardziej prawidłowo" to chyba bez sensu.

Nie zamierzam prowadzić walki z wiatrakami. Nie chcesz to nie - Twoja sprawa. Wyłuszczyłem swoje argumenty, resztę pozostawiam w gestii Czytelników.

komentarz 25 sierpnia 2016 przez event15 Szeryf (93,790 p.)

Hmm...

https://github.com/google/styleguide

https://google.github.io/styleguide/cppguide.html

http://www.php-fig.org/

https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

http://docs.python-guide.org/en/latest/writing/style/

-----------------------

Kod doskonały. Jak tworzyć oprogramowanie pozbawione błędów. Wydanie II - Steve McConnell (Helion)
Agile. Programowanie zwinne - zasady, wzorce i praktyki wytwarzania oprogramowania - Robert C. Martin (Helion 2008)
Pragmatyczny programista. Od czeladnika do mistrza - Andrew Hunt, David Thomas (Helion 2014)
Zwinny samuraj. Jak programują mistrzowie zwinności - Jonathan Rasmusson
Czysty kod. Podręcznik dobrego programisty - Robert C. Martin
Mistrz czystego kodu. Kodeks postępowania profesjonalnych programistów - Robert C. Martin
Zwinne wytwarzanie oprogramowania. Najlepsze zasady, wzorce i praktyki - Robert C. Martin

xUnit Test Patterns - Gerard Meszaros (The Addison-Wesley Signature Series)
Software Testing. Concepts and Operations - Ali Mili (John Wiley & Sons 2015)

Architektura systemów zarządzania przedsiębiorstwem. Wzorce projektowe - Martin Fowler (Helion 2005)
Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku - Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides
PHP5. Obiekty, wzorce, narzędzia - Matt Zandstra
Wzorce implementacyjne - Kent Beck

Bertrand Meyer Programowanie Zorientowane Obiektowo.

Każdy język, każdy framework, każde narzędzie programistyczne wykorzystywane we wszystkich zakątkach świata mają swoje style guide i coding standards.

Każda firma na świecie mają swoje style, wypracowane latami doświadczenia. Ba każdy zespół w ramach jednej firmy ma wypracowane swoje standardy, które w różnych zespołach mogą być różne.

Dziś pracujesz w polskim teamie, a jutro może się okazać, że inny zespół przejął utrzymanie kodu. I co wtedy

Taki przypadek zaistniał na przykład w firmie GOG.com - producent gry Airline Tycoon Evolution udostępnił swój kod tej firmie. Jednakże GOG.com nie podjął się modyfikacji gry w celu poprawienia rozdzielczości, czy chociażby optymalizacji ponieważ cały kod został napisany po niemiecku. Ot co. W zamian udostępnili źródła ludziom, którzy mają na tyle odwagi.

Mnie takie modne trendy po prostu śmieszą. Pisanie zmiennych po polsku nie jest profesjonalne?

Byłem w zespole, który postanowił pisać w języku polskim. Jednak miało to solidne uzasadnienie i trwało wiele miesięcy zanim podjęto tę decyzję. Głównie chodzi o "język wszechobecny" towarzyszący projektom w ogromnej skali w metodologii DDD.

Dodam tylko że takich różnych widzimisię jest więcej. Ciekawe jak w zespole pisać klamry... Tam też jest niezła zagwozdka, co programista to pisze to inaczej...

Wiesz... w firmie dostajesz licencje na oprogramowanie (na przykład PHP ma PHPStorma), które przy kliknięciu Ctrl+Alt+L formatuje kod do wszelkich standardów ustalonych na spotkaniach w firmie i każdy może sobie pisać tak jak kocha, a na firmowym gitlabie zawsze jest porządek. Do tego istnieją narzędzia CodeStyle, Sniffery, Travisy i inne narzędzia do nadzorowania jakości kodu.

Ale mówienie komuś że tak jest "bardziej prawidłowo" to chyba bez sensu.

Racja - nie powinno się mówić, że coś jest bardziej prawidłowe. Powinno się mówić, że coś jest dziś standardem, lub nim się staje. Standardy są zmienne, ale chcąc utrzymać świeżość, a przede wszystkim kompatybilność i PEWNE działanie swojego projektu, należy pisać zgodnie z obecnymi standardami. Chociażby dlatego, że w pewnym momencie powstanie dług technologiczny. Gdy będzie on się rozrastać, to powstanie big ball of mud. W następstwie powstanie pętla refaktoryzacji i rotacja pracowników lub porzucenie projektu.

Tak duża liczba książek odnoszących się do jakości kodu wiąże się wyłącznie z wnioskiem, że masa kodu na świecie powstawała w sposób chaotyczny, robiąc kupę z wielu biznesów. Wystarczy otworzyć którąkolwiek książkę którą podałem, już na samych wstępach jest masa informacji o padniętych firmach w skutek pisania kodu złej jakości.

Wszystko przez tak zwane "pierdoły". Możesz nie rozumieć istoty problemu, ponieważ mogłeś nigdy nie mieć do czynienia z legacy code, który musi zacząć działać na wczoraj bo biznes straci miliardy. Widocznie jeszcze nie przeczytałeś wielu książek na temat programowania i zatrzymałeś się na 1 do trzech pozycji. Bo wątpię, żeby osoba która jest mocno oczytana w taki sposób się wypowiadała.

I uprzedzając - Comandeer potrafi niesamowicie dobrze uargumentować swoje stanowisko, gdy nie zgadza się z jakimś "dogmatem". U Ciebie zaś nie widziałem żadnego solidnego argumentu, który by mi przemówił do rozsądku, że mam odpuścić pisanie po angielsku kodu.

komentarz 25 sierpnia 2016 przez manjaro Nałogowiec (37,390 p.)
edycja 25 sierpnia 2016 przez manjaro

@event podziwiam Cie za wkład pracy jaki włożyłeś w napisanie tego postu. Nie che mi się tego ciągnąć. OK zdaje sobie sprawę że jednak ten angielski może się komuś na świecie kiedyś przydać. Ale gdzie tu sens abym moje zadania na spoja pisał po angielsku??? Wiem wiem zaraz powiecie ale przecież @draghan napisał że chodzi o pracę zespołową a nie to co pisze dla siebie tylko. Niemniej jednak w wielu miejscach na forum widziałem uwagi aby pisać zmienne po angielsku. No przepraszam ale dla mnie pisanie po polsku jest szybsze bardziej zrozumiałe i bardziej logiczne. A przede wszystkim jestem Polakiem i swój kod będę pisał w moim ojczystym języku. No chyba że sytuacja będzie wymagać czegoś innego. Ale generalnie nie będę się gimnastykował w domu z angielskim bo niby takie są standardy... Poza tym przykłady które przytoczyłeś z problemami językowymi to są naprawdę marginalne przypadki...

Idąc Waszym torem rozumowania to chyba należy wyrzucić strumienie z C++ bo są zbyt wolne... Mam rozumieć że w dużych firmach nie używa się strumieni bo są niewydajne i jest to nieprofesjonalne? Jeżeli tak to dlaczego Prata i Grębosz ich używają i nie widzą w tym nic złego?

I na koniec tylko dodam że 99% użytkowników tego forum nigdy nie osiągnie takiego poziomu profesjonalizmu aby te rady miały jakiekolwiek znaczenie.

komentarz 26 sierpnia 2016 przez event15 Szeryf (93,790 p.)

Książki Grębosza są równie aktualne jak fluksje Newtona, które dziś nazywamy różniczkami przypisując je innemu europejczykowi.

Newton używał nieczytelnego dla innych sposobu zapisu, Leibnz odkrył mniej więcej w tym samym czasie to samo (o co się procesował z Newtonem), z tym, że jego zapis okazał się dużo łatwiejszy. Od jego czasów nieco się zmieniłlo w zapisie, ale to normalna cecha ewolucji.

Mylisz autorytety - obaj panowie to fizycy, a nie profesjonalni programiści. Może nawet dobrzy dydaktycy. Nawet na swoje czasy pisali dobre książki. Grębosz od samego początku był kontrowersyjny w środowisku programistów. Racja - zdobył uznanie u wielu Polskich programistów i wykształcił miłość do programowania dzisiejszych zawodowców. Jednak każdy kto w latach świetności tej książki go czytał dziś już nie uznaje go za autorytet w dobrym i wysokiej jakości programowaniu. Nazwałbym tę książkę raczej wstępniakiem dla nastolatków, którzy jeszcze nie wiedzą czy chcą programować.

Wiedz również, że jeśli udostępnisz swój kod na GitHubie czy BitBuckecie a przyszły team leader spojrzy na Twój kod, może się okazać że uzna Cię za "gorszy sort" bo z miejsca widać że możesz sprawiać problemy. W końcu kto w dzisiejszych czasach pisze dobry kod po polsku? Prawdopodobnie desperaci lub ludzie, którzy nie znają angielskiego. Żadnego z tych dwóch bym nie zatrudnił, chociażby dlatego, że wszystkie dobre materiały dostępne w sieci (dokumentacje, kursy, stackoverflow, github itp) są w języku angielskim. Brak umiejętności rozumienia tego języka dyskwalifikuje kandydata. Pisanie po polsku, bo tak i już, może mi sygnalizować, że osoba będzie oporna w dostosowywaniu się do zasad które panują w firmie. Wystarczy, że wnerwi go głupia klamerka w innym miejscu albo nie da się przekonać że w tym a innym przypadku lepiej podnieść abstrakcję klasy do interfejsu albo zmienić nazwę metody na bardziej wymowną. Praca ma być przyjemnością, a wykłucanie się o takie "pierdoły" z mojego punktu widzenia dyskwalifikują takiego pracownika.

Poza tym jeśli chcesz pisać po polsku, to w kodzie myślę, że używasz znaków diakrytycznych?

I na koniec tylko dodam że 99% użytkowników tego forum nigdy nie osiągnie takiego poziomu profesjonalizmu aby te rady miały jakiekolwiek znaczenie.

Chciałbym poznać metodologię, na podstawie której wyliczyłeś taki procent. Jest tu masa użytkowników, którzy mają bardzo wysoki poziom pisania kodu. Jeszcze więcej jest użytkowników, którzy chcą stale poprawiać jakość swoich programów. Jest też część użytkowników, którzy próbują beznadziejnie przekonywać, że zmienne globalne są ok, gdy pisze się dla siebie, że nazywanie zmiennych monosylabami lub literkami jest fajne i przydatne w przypadku gdy pisze się dla siebie. Że nie ma znaczenia czy użyjemy PDO czy mysql_connecta gdy piszemy dla siebie.

Gdyby tak nazbierać te wszystkie "dla siebie" i pomnożyć je przez ilość dni, w których dany delikwent tak pisał, może nam wyjść rok, dwa, a nawet więcej lat doświadczenia w pisaniu gówna. To jest od 360 dni do powyżej tysiąca. A człowiek jest tak skonstruowany, że czynność powielana przez ok. 30 dni staje się już nawykiem. A nawyków już tak łatwo nie da się pozbyć lub zmienić.

W przypadku PHP w jednym roku zostały wydane dwie książki. Żółta biblia, która do dziś jest wielkim bestsellerem, wyrocznią i świątynią dla wielu programistów PHP - w rzeczywistości jeden wielki crap z przerażającą ilością złych nawyków, przestarzałych funkcji i zabiegów, bez wykorzystania (już) ówcześnie znanych narzędzi do testowania.

Druga zaś, Matt'a Zandstry - traktująca o wzorcach projektowych, będąca poniekąd opowieścią autora o zamiłowaniu do tworzenia pięknego, modulanrego kodu.

Obie wydane w tym samym roku. Oznacza to, że można było pisać wtedy gówno, albo coś naprawdę dobrego - do tego rozumieć to, co się pisze. Żółta książka wygrała ze wszystkimi innymi pozycjami z prostego względu. Była pisana jak dla nastolatka, dziecka z nadmiarem czasu i niedoborem energii, które woli siedzieć w domu niż biegać po dachach i drzewach. Po prostu forma książki jest niesamowicie prosta i sprawia wrażenie wyczerpującej wszystkie elementy języka.

Podsumowując, nigdy nie piszesz "dla siebie". Zawsze powinieneś pisać "dla kogoś". Tak aby inna osoba, z każdego krańca świata mogła zrozumieć, co tu chciałeś zrobić. Stąd powstały GRASPy, SOLIDY, DRY, Ubiquitous Language, Domain Specific Lanuage, Patterny, masa style guidów. Chodzi o ujednolicenie kodu. Samo dążenie do przestrzegania tych wszystkich standardów mówi wiele o osobie kandydata na programistę czy programiście. Widać, ze człowiek ciągle się rozwija, ciekawi go to, co robi, chce być na bieżąco. Są ludzie którzy praktycznie obudzeni w nocy wyrecytują Ci standardy w3c albo podadzą chociaż informacje potrzebne do wyszukania różnych rzeczy ( :) ) I takich ludzi nazywa się specjalistami - mają oni w sobie empatię i szacunek - dla siebie oraz wszystkich tych, którzy kiedykolwiek zajrzą w ten kod, który napisali przed chwilą. Niedostosowywanie się do reguł jedynie jest utrudnieniem, o czym się przekonasz w pierwszej lepszej pracy, jaką zdobędziesz.

komentarz 26 sierpnia 2016 przez unknown Nałogowiec (39,560 p.)

Jeśli wyłączysz synchronizacje z stdio, to cała przewaga scanf i printf nad strumieniami znika. Poza tym pisanie nazw po angielsku, ma też znaczenie ze względu na kompilatory i interpretory różnych języków, które zazwyczaj nie radzą sobie z polskimi znakami diakrytycznymi. Oczywyście można pisać bez nich, ale po co kaleczyć język ojczysty? No i jak już napisał event15, są pewne standardy, i jeśli nie będziesz się ich trzymał, to wylatujesz.