Ερωτηση για στυλ κωδικα

[Directx]

Προτιμώ το Allman, σπανιότερα γράφω και με K&R, για τις περιπτώσεις if και operators (&& κλπ) προτιμώ να τους στοιχίζω κάτω από το if.

 

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

[defacer]

Μιλάμε για ένα case όπου απλά το expression είναι μεγάλο έτσι; Με την περιγραφή σου στην ουσία καταργείς τα lambdas τα οποία εξ' ορισμού είναι functions μέσα σε functions επίσης ούτε θέμα με το test coverage δημιουργείτε, αν υπονοείς αυτό. Είναι σαν να μου λες να μην γράφω linq με lamdas γιατί είναι μέσα σε άλλο function και "παραβιάζεται το single responsibility principle".

 

Δε θέλω να καταργήσω τα lambdas, ίσως δεν το έθεσα σωστά. Το θέμα μου δεν είναι το construct της lambda αυτό καθ' αυτό. Έχω στο μυαλό μου ότι εννοείς να γράψεις κάτι τέτοιο:

Action<bool> isValid = () => foo.bar() && x < y && ...;

if (isValid()) ...

Εδώ η παραβίαση του SRP είναι πως η method 1) αποφασίζει αν κάτι είναι valid και 2) αν όντως είναι valid κάνει κάποια δουλειά.

 

Στην περίπτωση του LINQ από την άλλη, ας πούμε σ' αυτό εδώ το παράδειγμα:

strings.GroupBy(s => s[0]).Select(g => new {Letter = g.Key, Words = g.OrderBy(s => s.Length).ToList()})

δεν υπάρχει παραβίαση του SRP. H κάθε method κάνει μία δουλειά μόνο και η μαμά method κάνει απλά το composition για να υπολογίσει το επιθυμητό αποτέλεσμα.

 

Αντίστοιχα δεν υπάρχει παραβίαση του SRP αν προάγεις την isValid παραπάνω σε method.

 

Τώρα, εννοείται πως δεν τα λέω όλα αυτά επειδή παραβιάζοντας το SRP πρέπει να καείς στην πυρά. Απλά η συγκεκριμένη πρακτική (το να αποφασίσεις ότι χρειάζεται κάποιο refactoring και το refactoring αυτό να είναι η lambda) δεν κερδίζει τίποτα απολύτως σε σχέση με το να γινόταν refactoring κάνοντας την IsValid method. Φιλοσοφικά δηλαδή αν το δείς δεν έχει πλεονεκτήματα, έχει όμως μειονεκτήματα => wrong.

[Portmaster]

Δε θέλω να καταργήσω τα lambdas, ίσως δεν το έθεσα σωστά. Το θέμα μου δεν είναι το construct της lambda αυτό καθ' αυτό. Έχω στο μυαλό μου ότι εννοείς να γράψεις κάτι τέτοιο:

Action<bool> isValid = () => foo.bar() && x < y && ...;

if (isValid()) ...

Εδώ η παραβίαση του SRP είναι πως η method 1) αποφασίζει αν κάτι είναι valid και 2) αν όντως είναι valid κάνει κάποια δουλειά.

 

Στην περίπτωση του LINQ από την άλλη, ας πούμε σ' αυτό εδώ το παράδειγμα:

strings.GroupBy(s => s[0]).Select(g => new {Letter = g.Key, Words = g.OrderBy(s => s.Length).ToList()})

δεν υπάρχει παραβίαση του SRP. H κάθε method κάνει μία δουλειά μόνο και η μαμά method κάνει απλά το composition για να υπολογίσει το επιθυμητό αποτέλεσμα.

 

Αντίστοιχα δεν υπάρχει παραβίαση του SRP αν προάγεις την isValid παραπάνω σε method.

 

Τώρα, εννοείται πως δεν τα λέω όλα αυτά επειδή παραβιάζοντας το SRP πρέπει να καείς στην πυρά. Απλά η συγκεκριμένη πρακτική (το να αποφασίσεις ότι χρειάζεται κάποιο refactoring και το refactoring αυτό να είναι η lambda) δεν κερδίζει τίποτα απολύτως σε σχέση με το να γινόταν refactoring κάνοντας την IsValid method. Φιλοσοφικά δηλαδή αν το δείς δεν έχει πλεονεκτήματα, έχει όμως μειονεκτήματα => wrong.

Ή επιλέγεις τα παραδείγματά σου ή δεν έγινα εγώ ξεκάθαρος

 

Πες μου pls αν η διαφορά στα 2 παρακάτω χαζό snippets αποτελεί "παραβίαση" βάσει της λογικής σου.

var selected = new[] { 1, 2, 4 }
    .Where(x => x != 0 && IsMyMagicNumber(x));

vs

Func<int, bool> predicate = _ => _ != 0 && IsMyMagicNumber(_);

var selected = new[] { 1, 2, 4 }
    .Where(predicate);

 

[defacer]

Πες μου pls αν η διαφορά στα 2 παρακάτω χαζό snippets αποτελεί "παραβίαση" βάσει της λογικής σου.

 

Δεν έχουν καμία απολύτως διαφορά βάσει της λογικής μου. Είτε την παραβιάζουν και τα 2, είτε κανένα από τα 2 (ανάλογα με το τι κάνει το predicate όταν πάμε σε concrete υλοποιήσεις). Contrast όμως με το να βάλεις το predicate σε δική του method, στην οποία περίπτωση σίγουρα δεν την παραβιάζει (granted αυτό στην προκειμένη είναι τελείως θεωρητική παρατήρηση).

 

Απ' ότι κατάλαβα απλά είχαμε διαφορετικό πράγμα στο μυαλό μας.

[imitheos]

Προσωπικά σε 1920 πλάτος βρίσκω ότι με 80 chars με φτάνει ίσα ίσα για να έχω στο Eclipse 2 tabs με κώδικα + κάποιο στενό tab με code/project outline. Εντάξει όλα αυτά φυσικά είναι θέματα προσωπικής προτίμησης.

Ε ναι. Αλλά εννοείς δύο tabs side by side? Σε κάποιες περιπτώσεις το έχω κάνει και γω (αν και πλέον απλά ξεκολλάω το δεύτερο tab και το πετάω -- ή και τα δύο, αν χρειαστεί -- στη δεύτερη οθόνη) αλλά επί μονίμου βάσεως?

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

Δεν διάβασα όλο το νήμα οπότε ίσως να έχει ειπωθεί αλλά ένα άλλο πλεονέκτημα που παρουσιάζουν οι υποστηρικτές του 80 (εκτός από το ότι σε wide οθόνη μπορείς να έχεις 2 panels στο IDE ή και 3 τερματικά 80x25) είναι αυτό που ανέφερε ο DirectX. Από ένα μήκος και πάνω δεν φαίνεται ολόκληρη η σειρά στο μάτι με αποτέλεσμα να κάνεις κινήσεις δεξιά αριστερά.

 

Πήρα κάποια βιβλία που είχα στο γραφείο και μέτρησα μια τυχαία γραμμή από το καθένα και το αποτέλεσμα είναι το εξής: Πρώτο 78, Δεύτερο 69, Τρίτο 83, Τέταρτο 73. Φυσικά κάθε γραμμή δεν έχει τον ίδιο ακριβώς αριθμό γραμμάτων αλλά το μέγεθος της σελίδας σε συνδυασμό με το μέγεθος της γραμματοσειράς επιλέγεται ώστε στην απόσταση που θα διαβάζεις το βιβλίο να μπορείς να το βλέπεις ολόκληρο.

 

Σε ένα τερματικό - IDE - whatever, το 80 (άσχετα αν αρχικά δεν επιλέχθηκε για αυτό το λόγο) δεν είναι πολύ μεγάλο για να κουράζει.

[migf1]

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

 

Εγώ τουλάχιστον γράφω αρκετά συχνά κώδικα (βασικά συνεχίζω υπάρχοντες κώδικες) σε τρία διαφορετικά μηχανάκια: δυο λάπτοπ με 14.5" και 15.5" οθόνες, αντίστοιχα, και ένα desktop με 22" (για ένα διάστημα έγραφα σε δυο 22άρες, αλλά το κατάργησα συνειδητά... άλλη κουβέντα αυτή). Μου τυχαίνει επίσης, βέβαια πιο σπάνια, να γράφω κώδικα στο περιβάλλον του πελάτη (πριν από κάνα μήνα έγραφα php σε λάπτοπ πελάτη που είχε οθόνη 12").

 

Είναι επίσης νομίζω ένας από τους βασικούς λόγους που η συντριπτική πλειοψηφία των open source χρησιμοποιούν 80στηλο gutter. Από όσο γνωρίζω, τουλάχιστον για C, είναι σχεδόν αδιαπραγμάτευτο στάνταρ and for good reason (χωρίς αυτό να σημαίνει πως δεν υπάρχουν κι εξαιρέσεις, λίγες όμως).