Γενικό thread αποριών για τη C#.

[Kercyn]

Γιατί η TakeNumbers επιστρέφει int κι όχι bool; Μπορείς να κοιτάξεις επίσης και την TryParse αντί για τη σκέτη Parse. Αυτό που έχεις γράψει μπορεί να γραφτεί και έτσι:

 

 

int number = TakeNumbers();
if (number != 0)
{
    // . . .
}
else
{
   // end program
}

[Alithinos]

 

Γιατί η TakeNumbers επιστρέφει int κι όχι bool; Μπορείς να κοιτάξεις επίσης και την TryParse αντί για τη σκέτη Parse. Αυτό που έχεις γράψει μπορεί να γραφτεί και έτσι:

int number = TakeNumbers();
if (number != 0)
{
    // . . .
}
else
{
   // end program
}

 

Άμα όμως έβαζα το μήνυμα τερματισμού προγράμματος σε else, δεν θα εκτελούταν αν η συνθήκη του if είναι αληθής. Θέλουμε όμως να εμφανίζεται το μήνυμα και να αναμένεται πίεση πλήκτρου από το χρήστη, είτε ο χρήστης βάλει σωστά τον αριθμό είτε όχι.

Έτσι θα έπρεπε να γράψουμε τις γραμμές κώδικα από το else και μέσα στο μπλοκ του if, και θα επαναλαμβανόμασταν. Και η επανάληψη είπαμε ότι είναι κακό.

 

Σ' αυτό με τη bool έχεις δίκιο. Το έκανα γιατί όταν έγραφα την υπογραφή της μεθόδου θεώρησα ότι ίσως αργότερα να θέλω να προσθέσω επιπλέον κωδικούς, και έτσι ενστικτωδώς έβαλα int.

[V.I.Smirnov]

Η χρήση του goto αναθεματίστηκε επειδή γινόταν κατάχρηση και βοηθούσε τους απρόσεκτους,

τεμπέληδες, αρχάριους κλπ να γράφουν δαιδαλώδη κώδικα που ήταν δύσκολο να παρακολουθήσεις

τη ροή του από τα πολλά "πηδήματα" εδώ κι εκεί.

Αυτό είναι το νόημα, να μην έχεις "ροή-σπαγγέτι".

 

Το να το χρησιμοποιείς σποραδικά όταν σε διευκολύνει, δεν έχει τίποτε μεμπτό.

Στο απόσπασμά σου, το το if-else είναι πιο "βαρύ" οπτικά διότι εισάγει άλλο ένα block

ενώ το goto είναι πιο "λιτό" και "οικονομικό". Μια χαρά ταιριάζει λοιπόν.

 

-

[Kercyn]

Άμα όμως έβαζα το μήνυμα τερματισμού προγράμματος σε else, δεν θα εκτελούταν αν η συνθήκη του if είναι αληθής. Θέλουμε όμως να εμφανίζεται το μήνυμα και να αναμένεται πίεση πλήκτρου από το χρήστη, είτε ο χρήστης βάλει σωστά τον αριθμό είτε όχι.

Έτσι θα έπρεπε να γράψουμε τις γραμμές κώδικα από το else και μέσα στο μπλοκ του if, και θα επαναλαμβανόμασταν. Και η επανάληψη είπαμε ότι είναι κακό.

 

Σ' αυτό με τη bool έχεις δίκιο. Το έκανα γιατί όταν έγραφα την υπογραφή της μεθόδου θεώρησα ότι ίσως αργότερα να θέλω να προσθέσω επιπλέον κωδικούς, και έτσι ενστικτωδώς έβαλα int.

 

Άμα δε θες να υπάρχει else δε βάζεις else. Αν θες αυτά που έχεις στο τέλος να βγαίνουν πάντα θα έχεις μόνο το if.

[Alithinos]

Άμα δε θες να υπάρχει else δε βάζεις else. Αν θες αυτά που έχεις στο τέλος να βγαίνουν πάντα θα έχεις μόνο το if.

Άρα θα καλούσαμε τη μέθοδο TakeNumbers(), και ανάλογα το τι επιστρέφει θα εκτελούσαμε ένα μέρος κώδικα, ή θα το 'πηδάγαμε' πηγαίνοντας απ' ευθείας στον τερματισμό.

Αυτό θέλω και εγώ.. Απλά το έκανα με goto εδώ.

 

Άρα μου λες ότι αυτό:

static void Main(string[] args)
        {
            bool userInputIsCorrect = TakeNumbers();
            if (userInputIsCorrect == true)
            {
                Prosthesi a = new Prosthesi();
                a.TypeMessage();
                a.TypeResult(alfa, beta);

                Afairesi b = new Afairesi();
                b.TypeMessage();
                b.TypeResult(alfa, beta);
            }
            
            Console.WriteLine("The program will now end...");
            Console.ReadKey();
        }

Είναι καλύτερο από αυτό:

 static void Main(string[] args)
        {
            bool userInputIsCorrect = TakeNumbers();
            if (userInputIsCorrect == false)
                goto EndOfProgram;
            
            Prosthesi a = new Prosthesi();
            a.TypeMessage();
            a.TypeResult(alfa,beta);

            Afairesi b = new Afairesi();
            b.TypeMessage();
            b.TypeResult(alfa,beta);

            EndOfProgram:
            Console.WriteLine("The program will now end...");
            Console.ReadKey();
        }

Ότι δηλαδή είναι καλύτερη μια if από ένα label.

I see...

 

υ.γ. Η ενασχόληση μου τελικά με BASIC 1.1 όταν ήμουν μικρός μου φαίνεται μου έκανε περισσότερο κακό από ότι καλό.

[Kercyn]

Ναι. Εγώ τουλάχιστον μπορώ πολύ πιο εύκολα, γρήγορα και σίγουρα να δω τη ροή του κώδικα. Ακόμα και αν το label ήταν indented πιο έξω από τον υπόλοιπο κώδικα, έπρεπε να περάσω όλο τον κώδικα και να ψάχνω για goto σε κάθε γραμμή (τα οποία μπορεί και να στέλνανε σε διαφορετικά labels οπότε τρέχα γύρευε).

 

Για να το διαπιστώσεις και μόνος σου αυτό, μπορείς να κάνεις αυτό που σου είπε ο defacer. Δοκίμασε δηλαδή να κάνεις κάτι σχετικά μεγάλο και να δουλεύεις με goto (αποκλειστικά ή όχι). Άσε τον κώδικα για ένα μήνα και μετά πήγαινε και ξανακοίτα τον.

[Alithinos]

Ξέρεις τι ? Προσωπικά τουλάχιστον, πχ σ αυτό το παράδειγμα μου φάνηκε αρχικά πιο 'εύκολο' το να βάλω label, γιατί βλέπω το κώδικα με τα δικά μου μάτια και τον διαχωρίζω μέσα στο κεφάλι μου σε μέρη, όπως και ένα αρχείο html, το οποίο έχει head, body, footer. Επί της ουσίας με τα labels είναι σαν να κάνεις markup τον κώδικά σου, και μου φάνηκε έτσι και λόγο αυτού πως είναι πιο 'δομημένο' με αυτό το τρόπο, αν και από ότι διάβασα στο λινκ που μου έδωσε ο defacer, structured programming είναι το ακριβώς αντίθετο.

 

Απ' την άλλη θα μου πεις θα μπορούσα να κάνω 'tag' πχ το κώδικα που ήδη έχω στη Main με αυτή τη λογική, και πάλι χωρίς να χρησιμοποιήσω καθόλου goto, αλλά περισσότερες μεθόδους. Πχ:

static void Main(string[] args)
        {
            bool userInputIsCorrect = TakeNumbers();
            MakeMath(userInputIsCorrect);
            EndProgram();
        }
        
        static void EndProgram()
        {
            Console.WriteLine("The program will now end...");
            Console.ReadKey();
        }
        static void MakeMath(bool n)
        {
            if (n == true)
            {
                Prosthesi a = new Prosthesi();
                a.TypeMessage();
                a.TypeResult(alfa, beta);

                Afairesi b = new Afairesi();
                b.TypeMessage();
                b.TypeResult(alfa, beta);
            }
        }

[albNik]

Η goto μπορει να χρησιμοποιηθει αν θες να βγεις απο ενα διπλό-τριπλό nested loop και όχι για ψύλλου πήδημα 

 

Η παράμετρος της MakeMath είναι τελείως άκυρη. Εφτιαξες μια συνάρτηση που αν κληθεί με n=false δεν κάνει τίποτα, άρα γιατί να την καλέσεις??.

Επίσης if(a==true) ειναι το ιδιο με if(a)

if(Takenumbers())
  MakeMath();
EndProgram();

[defacer]

To να χρησιμοποιήσουν κάποιο desisgn pattern δεν τους βόλευε επειδή θα αποκρύπτονταν πράγματα που ήθελαν να φαίνονται για να έχουν εποπτεία της ροής.

 

Με το μάτι την έχουν την εποπτεία της ροής; Τέλος πάντων.

 

Όσον αφορά το goto vs κάτι άλλο, νομίζω έχουμε εξαντλήσει το παραγωγικό περιθώριο της κουβέντας. Κάποιοι ήδη έδωσαν την απάντηση στο πώς χωρίς goto, την οποία απορρίπτεις συνοπτικά γιατί έτσι. Δε θέλω να βγάλω συμπεράσματα για τον κώδικα και τη δομή του από ένα μικρό μόνο τμήμα που δεν είναι αρκετό για να έχεις context, και σίγουρα όχι να ξεκινήσω υποθέτοντας πως αυτοί που έγραψαν τον κώδικα υπολείπονταν των απαιτήσεων (μια υπόθεση που όμως πολλές φορές ισχύει ακόμα κι εκεί που δεν το περιμένει κανείς, και δε μιλάω συγκεκριμένα για τους συγγραφείς του παραπάνω).

 

Από την άλλη όμως είμαι σίγουρος ότι μπορείς να με καταλάβεις όταν λέω ότι η επαγγελματική μου εμπειρία δε μου επιτρέπει να δέχομαι τέτοιες δηλώσεις επί τη εμφανίσει, ειδικά από κάποιον που δεν το κρύβει πως η ενασχόλησή του με τον προγραμματισμό περιορίζεται στα απολύτως απαραίτητα για να πετύχει στόχους που δεν έχουν να κάνουν αμιγώς με software engineering.

 

Εκεί βρίσκεται νομίζω και η διαφορά μας: εσύ βλέπεις ως το πραγματικό engineering challenge το να υλοποιηθεί ο ζητούμενος αλγόριθμος σωστά, και τα κριτήριά σου είναι αυτά του χρήστη του αλγορίθμου. Εγώ ως σημαντικότερο engineering challenge βλέπω το σχεδιασμό της βέλτιστης υλοποίησης και τα κριτήριά μου είναι αυτά του συγγραφέα και maintainer. Λογικό δεδομένου του ρόλου του καθενός.

 

Χμμ... Όταν θα δουλέψουμε μαζί με άλλους ανθρώπους οι οποίοι ίσως να μη χρειάζεται να γνωρίζουν την υλοποίηση του τάδε component, αλλά η δουλειά τους απαιτεί τη χρήση του component, και έτσι 'προστατεύουμε' το κώδικα για να μη τα κάνουν μαντάρα ?

 

Αφού μιλάμε για το goto, θα παραθέσω και εγώ ένα κομμάτι κώδικα, να μου πείτε αν είναι καλή εδώ η χρήση του ή όχι

 

Όχι ακριβώς. Το sealed, ειδικά στην περίπτωση που μιλάμε για code base όπου έχουμε πρόσβαση, είναι ένα μήνυμα από το designer της class: είτε για έναν ή περισσότερους λόγους οι επιλογές που έγιναν στην υλοποίησή της δείχνουν προς άλλο μοντέλο χρήσης από inheritance, είτε δεν ελήφθη καν η περίπτωση του inheritance υπόψη κατα το design. Και ο λόγος που το βάζεις είναι να περάσεις αυτό το μήνυμα σε όποιον δει την class (γιατί κατά τα άλλα, το να κάνεις unseal την class είναι γενικά εφικτό αν το θες οπότε το sealed δεν είναι ουσιαστικό εμπόδιο αλλά ισχυρό hint).

 

Τώρα ο κώδικας που δίνεις, δεν είναι ιδιαίτερα καλός. Υπάρχουν πολλά σημεία που σηκώνουν βελτίωση και πολλοί διαφορετικοί τρόποι για να γίνει η βελτίωση. Ας ξεκινήσω με μια απλή πρόταση: η main κάνει τρία πράγματα: παίρνει είσοδο, εκτελεί εργασία, και τυπώνει μήνυμα. Για να γίνουν όλα αυτά δεμένα όπως θέλουμε βάλαμε goto. Μπορούμε όμως απλά να κάνουμε up the design αφαιρώντας μία (άσχετη με τις υπόλοιπες) από τις αρμοδιότητες της main και βγάζοντάς τη σε άλλη method:

static void Main(string[] args)
{
    DoYourStuff();
    GracefulExit();
}

static void DoYourStuff() // πρώην main
{
    int number = TakeNumbers();
    if (number == 1) return; // χωρίς goto

    Prosthesi a = new Prosthesi();
    a.TypeMessage();
    a.TypeResult(alfa,beta);

    Afairesi b = new Afairesi();
    b.TypeMessage();
    b.TypeResult(alfa,beta);
}

static void GracefulExit()
{
    Console.WriteLine("The program will now end...");
    Console.ReadKey();
}

Τι πετύχαμε έτσι:

1. Η main έγινε δύο γραμμές που είναι μάλιστα self-documenting. Με ένα καλύτερο όνομα για τη DoYourStuff τώρα κάποιος θέλει 3 δευτερόλεπτα για να πάρει μια ιδέα του πώς θα εξελιχθεί σε γενικές γραμμές η εκτέλεση του προγράμματος.
2. Οι άλλες δύο methods είναι, κάθε μία χωριστά αλλά και το άθροισμά τους επίσης, ευκολότερες στην κατανόηση από την πρώην main.
3. Τελείως όχι τυχαία, κάτι που κάνει την DoYourStuff πολύ ευκολότερη από την πρώην main είναι το γεγονός ότι δεν υπάρχει πλέον goto αλλά return στη θέση του. Το λεπτό σημείο είναι πως διαβάζοντας τώρα τη DoYourStuff και φτάνοντας στο return αμέσως κλείνει στο μυαλό του αναγνώστη το κεφάλαιο "τι θα γίνει αν το number είναι 1" και προχωράει παρακάτω με ένα λιγότερο πράγμα στο μυαλό του. Αντίθετα πριν με τη goto μόλις φτάσεις σε κείνο το σημείο όχι απλά δεν κλείνει το κεφάλαιο αλλά βάζεις επιπλέον mental note "μόλις βρω αυτό το label να θυμηθώ πως ο,τι ακολουθεί γίνεται και στην περίπτωση number ίσον 1". Για να το πω πιο χαριτωμένα, ο ανθρώπινος parser χρειάζεται λιγότερο internal state στην περίπτωση του return παρά του goto. Και η επίτευξη του λιγότερου internal state είναι ευγενής στόχος.

 

Τώρα γενικά, υπάρχουν κι άλλα μαργαριτάρια στο αρχικό πρόγραμμα και δεν είναι της παρούσης να τα πιάσουμε όλα. Επίσης είναι ίσως εύλογο να αναρωτηθεί κανείς αν όντως έχει πρακτική σημασία η (αποδεδειγμένη παραπάνω θέλω να ελπίζω) "απλοποίηση με την εισαγωγή επιπλέον method", το πρόγραμμα που βλέπουμε είναι τετριμμένο και σιγά τα λάχανα που θα μας μπέρδευε ένα goto. Σε όποιον προκύψει αυτή η αμφιβολία έχω να πω τα εξής:

• Οι ίδιες ακριβώς τεχνικές που δεν έχουν και τόση πρακτική σημασία σε τετριμμένα προγράμματα είναι η διαφορά ανάμεσα στη ζωή και το θάνατο σε πραγματικού μεγέθους προγράμματα, τα οποία προφανώς είναι τάξεις μεγέθους πιο πολύπλοκα και δύσκολα στην κατανόηση από το παραπάνω παράδειγμα, και πάνω στα οποία δε δουλέυει ένας developer αλλά 10-100-500.
• Εκτός από τα πραγματικού μεγέθους προγράμματα όμως, εφόσον ξέρει κανείς τον τρόπο για να απλοποιήσει την κατάσταση γιατί να μην κάνει την καλύτερη δουλειά που μπορεί ακόμα και σε κάτι απλό; Εξάλλου τελειοποιώντας την ικανότητα στο design δε "χάνει κανείς χρόνο" αλλάζοντας ανούσια τα goto σε return. Απλά γράφει τα return με την πρώτη, και τα goto δεν περνάνε καν από το μυαλό.
• Προσωπικά θεωρώ τη βελτίωση σε οποιοδήποτε aspect του προγραμματισμού αυτοσκοπό οπότε το ενδεχόμενο ερώτημα "γιατί όμως να μάθει κανείς τον τρόπο να απλοποιήσει την κατάσταση πριν αναγκαστεί" για μένα είναι άτοπο. Είμαι μουσικός, η ερώτηση γιατί ασχολείσαι με κιθάρα αφού στη μπάντα μόνο παίζεις σαξόφωνο δε χρειάζεται απάντηση.

 

 

ΥΓ1: Το ίδιο πράγμα στο οποίο αναφέρομαι παραπάνω ως "human parser internal state" το αναφέρει και ο Kercyn λέγοντας "Ακόμα και αν το label ήταν indented πιο έξω από τον υπόλοιπο κώδικα, έπρεπε να περάσω όλο τον κώδικα και να ψάχνω για goto σε κάθε γραμμή". Και όντως έτσι είναι. Βλέπεις το label και αρχίζεις να προετοιμάζεσαι για τα χειρότερα, χωρίς να ξέρεις καν ποιά μπορεί να είναι αυτά.

 

ΥΓ2: Το παραπάνω του AlbNik επίσης είναι στο ίδιο μοτίβο με τη δική μου πρόταση, μόνο η λεπτομέρεια του πού είναι το if αλλάζει.

[V.I.Smirnov]

Και το υπόλοιπο πρόγραμμα (του δικού post) είναι περίπου στο ίδιο στυλ.

 

Έχεις δίκιο σε αυτό που λες.

Το συγκεκριμένο πρόγραμμα ξεκίνησε να γράφεται δίχως μακρόπνοο σχεδιασμό και κατέληξε έτσι. 

Δυστυχώς, το αντικείμενο ήταν ξένο σε software engineers οπότε δεν μπορούσε να γίνει σωστή

σχεδίαση διότι αυτοί δεν μπορούσαν να καταλάβουν και να  εκτιμήσουν τη σημασία των επιμέρους

τμημάτων του.

Δεν ξέρω πολλά από sοftware engineering αλλά ο συνολικός αλγόριθμος ήταν τόσο πολύπλοκος

(πολλές σελίδες) ώστε και η αρχική σχεδίαση θα ήταν μια ιστορία από μόνη της.

Ωστόσο, ο σκοπός επετεύχθη κι έτσι : το πρόγραμμα δούλευε και παραδόθηκε.

 

Θεωρώ ότι το πρωταρχικό και πιο δύσκολο είναι να γράψεις κάτι που λειτουργεί σωστά.

Η συντήρηση και το refactoring είναι ένα σκαλί πιο κάτω επειδή για να έχουν έννοια πρέπει αρχικά να

μπορείς να γράψεις μια υλοποίηση, καλή ή κακή, που όμως να λειτουργεί σωστά.

Εν προκειμένω, αν δεν μπορούσαμε να υλοποιήσουμε τον αλγόριθμο δεν θα υπήρχε καν πρόγραμμα και project.

To ότι δεν οργανώθηκε σωστά δεν μας εμπόδισε να φτάσουμε στο τέρμα, έστω και με κακό τρόπο.

Το αντίθετο όμως, να γίνει καλή αρχική σχεδίαση αλλά να μην μπορούμε να υλοποιήσουμε τις λεπτομέρειες,

δεν θα κατέληγε πουθενά.

Προς αποφυγή παρεξηγήσεων, τα παραπάνω δεν σημαίνουν ότι υποτιμώ τη σημασία του software engineering.

H σημασία του όμως φαίνεται σε μεγάλα και πολύπλοκα projects. Σε προγράμματα των 1000 γραμμών οι κακές

συνήθειες δεν έχουν μεγάλες επιπτώσεις : είναι εύκολο να ξαναγράψεις το πρόγραμμα διαφορετικά αφού

έχεις εξασφαλίσει ότι δουλεύει.....

 

-

[groot]

Το ζητούμενο κάποιου που δεν είναι ΙΤ, είναι να δουλεύει ο αλγόριθμος.

 

Το ζητούμενο κάποιου που είναι ΙΤ, είναι να δουλεύει και να έχει γραφτεί σωστά. Όπου ως "γραφτεί" νοείται σωστή σχεδίαση για να επιτρέψει εύκολη επέκταση και συντήρηση αλλά και να υπακούει ένα νοητικό μοντέλο.

 

 

Σε παλαιότερες εποχές, γινόντουσαν ταρζανιές διάφορες αλλά λόγω ταχύτητας εκτέλεσης. Πλέον δεν είναι τόσο αναγκαίο, λόγω πιο φθηνών πόρων.

 

 

Σε κάθε περίπτωση, το "με goto δουλεύει, άρα το goto είναι σωστό" δείχνει άνθρωπο που δεν έχει καμία ιδέα περί software engineering. Τα ευτράπελα ξεκινάνε όταν αυτός ο άνθρωπος εκφέρει και γνώμη για την επαγγελματική πορεία software engineers και τις επαγγελματικές επιλογές αυτών.

[M2000]

Τα ευτράπελα υπάρχουν όταν κάποιος ξεκινάει από ένα goto και συνδιάζει το ποιος λέει τι για να απαξιώσει την γνώμη του άλλου, σε ένα φόρουμ που συμμετέχει με ψευδώνυμο, χωρίς καν να έχει παρουσιάσει το ποιος είναι....αλλά να πιστεύει ότι αρκεί μια φιλική αποδοχή, επειδή τυγχάνει και άλλοι να έχουν την ίδια γνώμη με αυτόν, ώστε να δημιουργεί την ιδέα ότι είναι όντως κάποιος που μπορεί να κρίνει αν κάποιος έχει γνώση για να εκφέρει γνώμη.

[defacer]

Θεωρώ ότι το πρωταρχικό και πιο δύσκολο είναι να γράψεις κάτι που λειτουργεί σωστά.

Η συντήρηση και το refactoring είναι ένα σκαλί πιο κάτω επειδή για να έχουν έννοια πρέπει αρχικά να

μπορείς να γράψεις μια υλοποίηση, καλή ή κακή, που όμως να λειτουργεί σωστά.

Εν προκειμένω, αν δεν μπορούσαμε να υλοποιήσουμε τον αλγόριθμο δεν θα υπήρχε καν πρόγραμμα και project.

To ότι δεν οργανώθηκε σωστά δεν μας εμπόδισε να φτάσουμε στο τέρμα, έστω και με κακό τρόπο.

Το αντίθετο όμως, να γίνει καλή αρχική σχεδίαση αλλά να μην μπορούμε να υλοποιήσουμε τις λεπτομέρειες,

δεν θα κατέληγε πουθενά.

 

Ναι, καταλαβαίνω. Από τη δική μου οπτική το να γράψεις κάτι που λειτουργεί σωστά είναι δεδομένο, οπότε το ενδιαφέρον μετατοπίζεται στο επόμενο στάδιο.

[M2000]

Δεν υπάρχει περίπτωση να γράψει κανείς κώδικα, για κάτι που πρώτη φορά σκέφτηκε, και να του πετύχει με την μία! Δηλαδή συνήθως γράφουμε κάτι που νομίζουμε ότι είναι σωστό, επειδή τυγχάνει να έχουμε στο νου μας μια κατάσταση, π.χ. κάποιες τιμές, και βλέπουμε ότι γίνεται αυτό που περιμένουμε. Όμως ενδέχεται να έχουμε κάτι άλλο σε πραγματικές συνθήκες, όπου δεν δίνουμε εμείς την είσοδο, ή δεν την δίνουμε στα παραδείγματα που ελέγχουμε, και τότε να δούμε ότι δεν είχαμε υπολογίσει μια λεπτομέρεια. Τότε ίσως ένα goto απλά να έβαζε μια διακλάδωση όμορφα προς το τέλος της συνάρτησης για να τελειώνουμε με το θέμα, παρά να γράψουμε πάλι νέο κώδικα,  με ένα στάδιο πριν την κλήση στη συνάρτηση, διότι αυτό μπορεί να απαιτούσε δουλειά σε πολλά σημεία του προγράμματος, ή να κάνουμε μια αλλαγή ονόματος, και να γράψουμε μια άλλη συνάρτηση που θα καλέσει την προϋπάρχουσα στην μια περίπτωση ή την νέα συνάρτηση στην άλλη.  Αμέσως όμως βάζουμε στο κώδικα στο τελικό exe, έμμεσα το ίδιο πράγμα, μια διακλάδωση, αλλά επιπλέον βάζουμε και πρόσθετη εργασία, χρήση του stack για πέρασμα τιμών. Με ένα απλό goto μοιράζουμε το κώδικα της συνάρτησης στα δύο. Όχι για να προσθέσουμε λειτουργικότητα, αλλά για να διορθώσουμε το έλλειμμα αυτής, γιατί υποτίθεται ότι είχαμε την ιδέα ότι γράφαμε κάτι που λειτουργούσε σωστά, το είχαμε δεδομένο!

[Kercyn]

Δεν υπάρχει περίπτωση να γράψει κανείς κώδικα, για κάτι που πρώτη φορά σκέφτηκε, και να του πετύχει με την μία! Δηλαδή συνήθως γράφουμε κάτι που νομίζουμε ότι είναι σωστό, επειδή τυγχάνει να έχουμε στο νου μας μια κατάσταση, π.χ. κάποιες τιμές, και βλέπουμε ότι γίνεται αυτό που περιμένουμε. Όμως ενδέχεται να έχουμε κάτι άλλο σε πραγματικές συνθήκες, όπου δεν δίνουμε εμείς την είσοδο, ή δεν την δίνουμε στα παραδείγματα που ελέγχουμε, και τότε να δούμε ότι δεν είχαμε υπολογίσει μια λεπτομέρεια. Τότε ίσως ένα goto απλά να έβαζε μια διακλάδωση όμορφα προς το τέλος της συνάρτησης για να τελειώνουμε με το θέμα, παρά να γράψουμε πάλι νέο κώδικα,  με ένα στάδιο πριν την κλήση στη συνάρτηση, διότι αυτό μπορεί να απαιτούσε δουλειά σε πολλά σημεία του προγράμματος, ή να κάνουμε μια αλλαγή ονόματος, και να γράψουμε μια άλλη συνάρτηση που θα καλέσει την προϋπάρχουσα στην μια περίπτωση ή την νέα συνάρτηση στην άλλη.  Αμέσως όμως βάζουμε στο κώδικα στο τελικό exe, έμμεσα το ίδιο πράγμα, μια διακλάδωση, αλλά επιπλέον βάζουμε και πρόσθετη εργασία, χρήση του stack για πέρασμα τιμών. Με ένα απλό goto μοιράζουμε το κώδικα της συνάρτησης στα δύο. Όχι για να προσθέσουμε λειτουργικότητα, αλλά για να διορθώσουμε το έλλειμμα αυτής, γιατί υποτίθεται ότι είχαμε την ιδέα ότι γράφαμε κάτι που λειτουργούσε σωστά, το είχαμε δεδομένο!

 

Νομίζω το παράδειγμά σου είναι εξαιρετικό παράδειγμα γιατί δεν πρέπει να χρησιμοποιούμε goto. Καταρχάς πριν ξεκινήσουμε να γράψουμε οτιδήποτε, πρέπει να το έχουμε σχεδιάσει και να ξέρουμε τι θέλουμε. Σίγουρα μπορεί στην πορεία να δούμε ότι κάποια πράγματα πρέπει να γίνουν αλλιώς ή να θέλουμε επιπλέον features (και συμβαίνει αυτό).

 

Αλλά όταν συμβεί αυτό, καθόμαστε και ξανασχεδιάζουμε τις αλλαγές που θέλουμε. Δε βάζουμε ένα goto επειδή "είναι εύκολο και δουλεύει". Γιατί όταν έρθει ο άλλος να κάνει maintain αυτό που έχουμε γράψει και βρει 100 goto "patches" σε όλο τον κώδικα, θα έρθει και θα μας βάλει φωτιά στο σπίτι. Επίσης, άμα θέλουμε στην πορεί να ξαναλλάξουμε κάτι τι θα κάνουμε; Θα πρέπει να κοπανάμε το κεφάλι μας για να καταλάβουμε τι κάνει ο κώδικας πρώτα και μετά πώς μπορούμε να τον διορθώσουμε;

 

Αυτή η "εύκολη και γρήγορη" λύση που σκεφτήκαμε μπορεί στο μέλλον να κοστίσει πολλαπλάσιο χρόνο απ' αυτόν που θα μας κόστιζε μια σωστά σχεδιασμένη λύση.