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

[M2000]

Μπορείς να έχεις σημειώσεις στο κώδικα. Και επίσης μπορείς να έχει και ολόκληρο συνοδευτικό κείμενο με την επεξήγηση του patch...Γιατί να δυσκολέψουμε το συνάδελφο...

 

(σωστά σχεδιασμένες λύσεις είναι όλες μέχρι να αποδειχθεί ότι δεν είναι)...

[Kercyn]

Γιατί δυσκολεύει την παρακολούθηση της ροής, δυσκολεύει το debugging και δείχνει τεμπέλικο και ερασιτεχνικό design. Αν χρησιμοποιήσεις goto, πρέπει να γράψεις ακριβώς γιατί το χρησιμοποιείς και γιατί μια εναλλακτική θα ήταν χειρότερη.

 

(σωστά σχεδιασμένες λύσεις είναι όλες μέχρι να αποδειχθεί ότι δεν είναι)...

 

Το ακριβώς αντίθετο. Όλες οι λύσεις είναι λάθος μέχρι να αποδείξεις με τον κώδικα και το documentation σου ότι ξέρεις ποιο είναι το πρόβλημα, ποια είναι η λύση και ότι η λύση έχει υλοποιηθεί σωστά. Σα να λέμε ό,τι γράφεις το κάνεις merge στο main branch και πας και λες στον PM "εμένα μου δούλεψε, κάτσε απόδειξέ μου ότι κάνω commit μαλακίες".

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

[V.I.Smirnov]

Το goto είναι μόνον μια από κάποιες δυνατότητες που μπορούν να καταστρέψουν το ευανάγνωστο του κώδικα.

Π.χ. μια κακή σχεδίαση ή ιεραρχία κλάσεων μπορούν να κάνουν το πρόγραμμα πολύ χειρότερο από μερικά goto.

Aλλά γι' αυτά ούτε κουβέντα. Σε κάθε ευκαιρία μόνον το goto καταδικάζετε...

 

-

[albNik]

Μπορείς να έχεις σημειώσεις στο κώδικα. Και επίσης μπορείς να έχει και ολόκληρο συνοδευτικό κείμενο με την επεξήγηση του patch...Γιατί να δυσκολέψουμε το συνάδελφο...

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

 

[Kercyn]

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

[M2000]

albNik, 

αυτά είναι γνώμες όχι κανόνες. Εγώ ελάχιστες φορές σημειώνω στο κώδικα..(και την έχω πατήσει)...

[albNik]

Ο λόγος που δίνουμε έμφαση στον σωστά δομημένο κωδικά είναι ότι κάνει πιο εύκολη τη ζωή μας όταν θα χρειαστεί να προσθέσουμε αργότερα κάποιο feature. 99.9% θα χρειαστεί να προσθέσεις ή να διορθώσεις κάτι.  Αν εισαι σίγουρος οτι δεν θα αλλάξει ποτέ πετάς τον κωδικα (μαζι με τα comments και το συνοδευτικο κείμενο) και κρατας μονο το exe.

[M2000]

@Kercyn

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

Εγώ συζητώ στο ότι αυτό που σου δίνουν δεν είναι το μόνο που θα αντιμετωπίσει ο κώδικας που θα τους δώσεις. Και όταν το μάθουν τότε τι θα κάνουν; Θα σου δώσουν πάλι δουλειά με νέο έλεγχο. Το αν εσύ βάλεις ένα "ιf a<5 and b>6 then goto ...." ή αντί για αυτό κάνεις το if then else άρα χωρίς goto...δεν είναι στη διάρθρωση το ζήτημα "κατανόησης" αλλά στο "if a<5 and b>6 then..." το οποίο αντιμετωπίζει το έλλειμμα...

@albNik,

Πράγματι έτσι γίνεται, όταν για παράδειγμα χρησιμοποιείς ρουτίνες από κάποιο dll. Δεν έχεις δει ποτέ το κώδικα αλλά το χρησιμοποιείς!

[albNik]

Τον κωδικα του dll τον έχει και τον συντηρεί ο κατασκευαστής του. Αν όμως όταν σου δίνει το dll πρέπει να σου δώσει και ένα τόμο συνοδευτικό κείμενο όπου σου εξηγεί τα ακροβατικά του τοτε πας στον επόμενο. 

[M2000]

Και όμως αυτό γίνεται.. παίρνεις ένα τόμο συνοδευτικό (για τη χρήση του). Αλλιώς τι υποστήριξη θα έχεις αν αγοράσεις μια άδεια χρήσης;

[moukoublen]

Το goto είναι μόνον μια από κάποιες δυνατότητες που μπορούν να καταστρέψουν το ευανάγνωστο του κώδικα.

Π.χ. μια κακή σχεδίαση ή ιεραρχία κλάσεων μπορούν να κάνουν το πρόγραμμα πολύ χειρότερο από μερικά goto.

Aλλά γι' αυτά ούτε κουβέντα. Σε κάθε ευκαιρία μόνον το goto καταδικάζετε...

 

-

 

Μα  δεν είναι μόνο το ευανάγνωστο όταν μιλάμε για όρους όπως maintainability, extensibility και ίσως σε κάποιες περιπτώσεις και optimization.

 

Θέλω να σε ρωτήσω σε αυτό το σημείο χωρίς -πραγματικά- καμία διάθεση ειρωνείας (το τονίζω γιατί ο γραπτός λόγος είναι παράξενο πράγμα).

 

Γενικότερα έχεις αίσθηση του τι εστί software engineering σήμερα;

(το μέγεθος που έχει πλέον και πόσα και ποια πράγματα υπάγονται σε αυτό. Γιατί έχουν δημιουργηθεί τι ανάγκες πάνε να καλύψουν; Τι μεγέθη λογισμικού υπάρχουν σήμερα και τι βαθμό πολυπλοκότητας έχουν; Τι σημαίνει ο βαθμός πολυπλοκότητας που αναφέρω πέρα από το επιστημονικό και abstract "πολυπλοκότητα αλγορίθμου").

 

Τι θέλω να πω:

Γνωρίζω ελάχιστα φυσική. Έχω όμως συναίσθηση του ότι είναι ελάχιστο αυτό που γνωρίζω μπροστά στο σύνολο της επιστήμης της φυσικής που υπάρχει σήμερα.

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

 

1) Προσπαθώ μόνον με βάση το ελάχιστο που γνωρίζω να κατανοήσω το θέμα αυτό και να έχω άποψη για το πόσο σημαντικό ή πολύπλοκο ή βαθύ είναι.

 

2) Κατανοώ και έχω συναίσθηση της ελλιπής μου γνώσης οπότε αντιστέκομαι στο ένστικτο που μου λέει (έλα σχημάτισε μια άποψη για αυτό που ακούς να τελειώνουμε) και δεν σχηματίζω καμία άποψη. Αντιθέτως κατανοώ ότι δεν μπορώ να το προσεγγίσω το θέμα και εαν θελήσω να το κάνω πρέπει να ακολουθήσω ένα συγκεκριμένο δρόμο γνώσης και πληροφόρησης.

 

Κατά τη δική μου άποψη -και θα το πω ευθέως- το πρώτο (1) με κάνει ανόητο.

 

 

Όταν λοιπόν η άποψη για το goto δεν έχει διατυπωθεί μόνο απο τον κάθε τυχάρπαστο π.χ. moukoublen σε ένα φόρουμ αλλα αντίθετα απο πολύ μεγάλες ομάδες και κοινότητες που βρίσκονται στον πυρήνα αυτού που λέμε σήμερα software engineering έχουμε πάλι μπροστά μας τις 2 εναλλακτικές που ανέφερα. 

 

Και ξέρεις λυπάμαι -γιατί αρκετά post σου τα έχω διαβάσει με ιδιαίτερο ενδιαφέρον στο παρελθόν-  γιατί αν έχω καταλάβει καλά βρίσκεσαι στον επιστημονικό χώρο αλλά κάτι τέτοια πράγματα που γράφεις και κάτι "χειρώνακτες προγραμματιστές" σε άλλα threads μου δίνουν την αίσθηση πως έχεις απολέσει της 2ης προσέγγισης που αναφέρω και που πιστεύω κατακτά κανείς όταν εμβαθύνει πολύ σε οποιοδήποτε τομέα γνώσης και μόρφωσης (ανεξάρτητα του ποιος είναι αυτός). 

[groot]

Απόδειξη ότι το goto είναι σωστό:

 

Το goto είναι λάθος. Το Χ είναι λάθος. Άρα το goto είναι σωστό.

[Giorgos65ert]

offtopic

 

Απόδειξη ότι το goto είναι σωστό:

Το goto είναι λάθος. Το Χ είναι λάθος. Άρα το goto είναι σωστό.

Αν το πάρουμε από μια άλλη οπτική γωνιά βγαίνει ορθή η απόδειξη .

 

Ας αποδείξουμε ότι η goto είναι σωστή για χρήση.

 

Θεωρούμε ότι δεν είναι καλή για χρήση η goto άρα θα είναι η X σωστή. (1)

Κάνουμε πραξούλες ...

Και βγαίνουμε σε άτοπο! (2)

 

Από τις σχέσεις (1) και (2) συμπεραίνουμε ότι η goto είναι μια σωστή τακτική για την ανάπτυξη προγραμμάτων.

 

Οπότε το καινούριο μας θεώρημα:

Κατά την διάρκεια της ανάπτυξης ενός προγράμματος(μεγάλου η μικρού) η χρήση της goto είναι απαραίτητη για την καλύτερη αξιοπιστία του προγράμματος μας.

 

// (Φυσικά αποτελεί ένα αστείο, και δεν ισχύει)

 

/offtopic

[defacer]

Το goto είναι μόνον μια από κάποιες δυνατότητες που μπορούν να καταστρέψουν το ευανάγνωστο του κώδικα.

Π.χ. μια κακή σχεδίαση ή ιεραρχία κλάσεων μπορούν να κάνουν το πρόγραμμα πολύ χειρότερο από μερικά goto.

Aλλά γι' αυτά ούτε κουβέντα. Σε κάθε ευκαιρία μόνον το goto καταδικάζετε...

 

Και τι να λέει αυτό; Δεν είναι κουβέντα καφενείου αυτή να έχει καθένας την ομάδα που υποστηρίζει και να κράζει τις άλλες. Προσωπικά καταδικάζω το goto γιατί είναι πολύ δύσκολο να κάνεις καλή χρήση του και ταυτόχρονα πολύ εύκολο να κάνεις κακή χρήση. Επίσης είναι πολύ απλό σαν concept το οποίο σημαίνει πως η κακή χρήση γίνεται ακόμα ευκολότερα από αρχάριους. Ή αν προτιμάς, και τα lightsabers τα καταδικάζουμε για ιδιωτική χρήση αλλά κυρίως θα μας ακούσεις να κράζουμε πιστόλια.

 

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

[Alithinos]

Όχι ακριβώς. Το 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 αλλάζει.

 

Ομολογουμένως είμαι άσχετος ακόμα από design, για αυτό και κάνω τέτοιες πατατιές. Κυρίως (ως τώρα) έχω ασχοληθεί περισσότερο με το να μάθω τις λειτουργίες της C#, που ακόμα έχω μπόλικες μπροστά μου. Την εκμάθηση όλων των υπολοίπων την έχω βάλει προσωρινά σε παύση, μέχρι να μάθω να κάνω τα όσα περιέχει το βιβλίο της C# που διαβάζω τώρα, ώστε να μπορώ να λύσω σωστά όλες τις ασκήσεις που έχει σε κάθε κεφάλαιο.

 

Γνωρίζω φυσικά πως αυτό το βιβλίο α' δεν αναφέρεται στα στοιχεία των εκδόσεων 4,5,6, και για αυτό σκοπεύω αφού τελειώσω το διάβασμα με το τρόπο που είπα και εξασκηθώ αρκετά σε αυτά που έχω μάθει για να μου χαρακτούν καλύτερα στη μνήμη και να τα κατανοήσω καλύτερα, να διαβάσω ένα καλύτερο, πιο πλήρες, βιβλίο για τη τρέχουσα έκδοση.

 

Σχετικά με design, εχω βάλει αυτό το βιβλίο στο μάτι:

 

 

Γιατί από κάτι samples που 'χω δει μ' αρέσει ο τρόπος παρουσίασης της σειράς αυτής.

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

 

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

 

1. Να μάθω τι κάνει και πως δουλεύει το κάθε τι που μπορώ να κάνω στη γλώσσα απ το βιβλίο που διαβάζω ήδη.

2. Να εξασκηθώ στη χρήση των όσων έμαθα ώστε να αποκτήσω περισσότερη οικειότητα μαζί τους, να δω πως αντιδρούν και συνδυάζονται μεταξύ τους, να βρω καλύτερους τρόπους που μπορούν να χρησιμοποιηθούν.

3. Να μάθω τη γενική θεωρία και για τις υπόλοιπες αφηρημένες δομές δεδομένων.

4. Να εξασκηθώ σε όλες τις ΑΔΔ όπως έκανα και για τα στοιχεία της C# στο 2.

5. Να διαβάσω ένα νέο βιβλίο που να καλύπτει και multithreading, async, και ένα σωρό άλλα πράγματα, τα οποία το βιβλίο που διαβάζω τώρα τα αφήνει απ' έξω.

6. Να εξασκηθώ στα όσα έμαθα από το νεότερο βιβλίο.

7. Να μάθω κάνοντας XAML, σχεδίαση GUI apps σε WinForms, ίσως και WPF.

8. Να μάθω πως να σχεδιάζω εφαρμογές (design patterns & principles) με βάση τα όσα ήδη ξέρω.

9. Να μάθω περισσότερα για το Engineering κομμάτι (Απαιτήσεις, Project Planning, Development Paradigms, Debugging, Maintenance).

10. Να μάθω HTML,CSS, ASP.NET.

 

Με το ρυθμό που πάω, και έχοντας ήδη ξεκινήσει το κεφάλαιο 11 του βιβλίου που παρέθεσα πιο πάνω του Herbert Schildt, θεωρώ ότι μέχρι το τέλος του Ιουνίου θα έχω τελειώσει το βιβλίο,και βάζω άλλο 1 μήνα για εξάσκηση όπου θα βάλω τα όσα έμαθα στη πράξη, και θα ξαναδιαβάσω κάποια σημεία που δεν θυμάμαι καλά, κάνοντας ολική επανάληψη, και λύνοντας ξανά όλες τις ασκήσεις με τη σειρά.

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

 

Από Σεπτέμβρη λοιπόν, αν όλα παν όπως προβλέπω, αρχίζει μια νέα αποχή, όπου πλέον θέλω να πιστεύω θα μπορούμε να συζητάμε μεταξύ άλλων και για design, με εμένα να μπορώ να συμμετέχω σε μια συζήτηση για αυτό.

 

Κάτι ακόμα: Συνολικά, από όταν το πήρα απόφαση πως θέλω να μάθω προγραμματισμό, το σύνολο μηνών που ασχολούμαι με την εκμάθηση είναι περίπου 6, με δύο σημαντικά διαστήματα παύσης ανάμεσα. Ξεκίνησα Δεκέμβρη του 2014, σταμάτησα Φεβρούαριο 2015 λόγο ενός προβλήματος υγείας που με ταλαιπώρησε μέχρι το Μάιο, έκανα μια επανάληψη περίπου τον Οκτώβριο του 2015 χωρίς να προχωρήσω παρακάτω, και μετά ξεκίνησα ξανά εντατικά από το Φεβρουάριο 2016. Άρα κρίνε με περίπου όπως θα έκρινες κάποιον φοιτητή του πρώτου εξαμήνου. Το λέω αυτό γιατί δεν θέλω να δώσω την εντύπωση του αδιάφορου ή του αμελούς για τα πράγματα που δεν ξέρω, αλλά να ξεκαθαρίσω τη θέση μου, ότι ξέρω ότι δεν ξέρω αρκετά πράγματα, και πως η μη πρόοδος μου σε ορισμένα θέματα (πχ design) οφείλεται στη σειρά με την οποία αποφάσισα να μάθω τα θέματα. Για μια περίοδο προσπάθησα να 'αντιγράψω' το τρόπο που μαθαίνουν στις σχολές, όπου κάθε μέρα μαθαίνουν και για κάποια διαφορετικά πράγματα. Αυτό όμως, ιδιαίτερα επειδή προσπαθώ να μάθω μόνος μου είναι πολύ δύσκολο, γιατί το αίσθημα προόδου γίνεται πολύ πιο αργό, και νιώθω πως είναι καλύτερο αν επικεντρώνομαι σε 1 πράγμα τη κάθε φορά αντί σε 10. 

 

Τη παραπάνω σειρά δηλαδή τη διάλεξα για αυτούς τους λόγους:

 

1. Γιατί μου φαίνεται πιο εύκολο να καταλάβω κάτι αν έχω μόνο αυτό το κάτι για να καταλάβω σε μια ημέρα.

2. Γιατί μου δίνεται η αίσθηση της προόδου καλύτερα, που παίζει κάποιον ρόλο στο motivation.

 

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

 

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

Το ξανακοίταξα το κώδικα σήμερα, και μου φαίνεται περίεργο που χθες μου φαινόταν πιο άμεσο το goto από ότι η χρήση while.

Κοίτα πως μπορεί να αλλάξει η αντίληψη του ανθρώπου σε μια μέρα... 

 

υ.γ. Ο κώδικας που παρέθεσα για το goto, προέκυψε με συγγραφή "στα τυφλά", με μηδενικό σχεδιασμό, θυμίζοντας τη big bang μεθοδολογία. Απλά έκατσα με ανοιχτό το VS και είπα "ωραία, τώρα ας βρω ένα τρόπο να χρησιμοποιήσω αυτά τα 2-3 features που έμαθα πρόσφατα", και εννοείται πως άμα αποφάσιζα να φτιάξω ένα σοβαρό project, θα ακολουθούσα τελείως διαφορετική τακτική.

Επεξ/σία 8 Μαΐου 2016 από Alithinos