Θα διαφωνήσω με το τελευταίο γιατί απλά, μόνο η VB έχει τέτοιο θέμα. Η C# δεν έχει θέμα και άνετα μπορείς να γράψεις το (private) πεδίο με μικρά και το property με κεφαλαία και να μην έχεις κανένα πρόβλημα. Άσε που αυτό είναι ήδη ένα από τα πιο συνηθισμένα conventions στη C#. Οπότε, αν δεν γράφεις με VB, γράφεις άνετα τα πεδία με μικρά. Παρεμπιπτόντως, και το δεύτερο πιο συνηθισμένο convention σε C#, C, C++, Java δεν παίζει σε VB, να βάζεις δηλαδή ένα _ μπροστά από τα ονόματα των πεδίων. Οπότε, είναι προτιμότερο να ακολουθείς ένα από τα δύο conventions που χρησιμοποιούν όλοι παρά να φτιάξεις ένα δικό σου.

Όσο για το να ξεχωρίσουν οι μεταβλητές και οι κλάσεις? Δεν βλέπω το λόγο - εκτός και αν ο κώδικας είναι εξαιρετικά κακογραμμένος. Διαφορετικά, απλά προσθέτοντας ένα C μπροστά από τον ορισμό ενός τύπου όπως κάναμε παλιά με την C++ καθαρίζεις. Οι μεταβλητές ποτέ δεν πρέπει να ορίζονται μακριά από το σημείο χρήσης τους, οπότε πάλι δεν πρέπει να υπάρχει πρόβλημα. Ακόμα όμως και αν κάποιος δεν είναι σίγουρος που ορίζεται ένας τύπος, μπορεί με ένα Go To Declaration ή βάζοντας το ποντίκι πάνω από τον τύπο να δει που ορίζεται μία κλάση.

Αντιθέτως, είναι πολύ πιο σημαντικό να χρησιμοποιεί κανείς επεξηγηματικά ονόματα για τους τύπους και τις μεταβλητές του. Αντί για i, j, k, c και μπόλικα comments καλύτερα να γράψει customerIndex, productID, secondsToExplosion, totalCars.

Να επαναλάβω, ότι αν ο κώδικας είναι κακογραμμένος και δεν ξεχωρίζει ποιός τύπος είναι του .NET και ποιός της εφαρμογής, υπάρχει πολύ σοβαρότερο πρόβλημα και θα πρέπει να αντιμετωπιστεί άμεσα. Αν οι μεταβλητές ορίζονται 3 σελίδες πριν χρησιμοποιηθούν, θα πρέπει να μεταφερθούν εκεί που χρησιμοποιούνται. Αν μία μέθοδος είναι 3 σελίδες θα πρέπει οπωσδήποτε να σπάσει σε μικρότερες. Μία μέθοδος ή μία κλάση θα πρέπει να είναι υπεύθυνη για ένα και μόνο ένα πράγμα. Μία συνάρτηση 3 σελίδων προφανώς προσπαθεί να κάνει πολλά πράγματα ταυτόχρονα και θα πρέπει να σπάσει. Μία κλάση με δεκάδες πεδία και properties, επίσης είναι ύποπτή. Είναι ελάχιστες οι φορές που χρειάζεται μία μεγάλη κλάση.

Όσον αφορά εργαλεία σαν το CodeRush, νομίζω ότι δεν βοηθάνε πολύ αν ο κώδικας είναι στοιχειωδώς καλογραμμένος. Αντίθετα, οι λειτουργίες refactoring του Refactor της ίδιας της Devexpress και του Resharper είναι πολύ πιο σημαντικές καθώς σε βοηθάνε να βελτιώσεις τον κώδικα.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Προσέχοντας λίγο τα guilelines του Brad Abrams είναι σαν να βλέπω πολλά από τα rules που επιβάλει το StyleCop. ...το οποίο παρεμπιπτόντως δεν είναι για καταστολή αλλά για να βοηθήσει μια ομάδα να γράφει με παρόμοιο τρόπο, καθώς πολύ εύκολα το configuration που επιλέγει κανείς μπορεί να γίνει κοινόχρηστο μέσω ενός shared folder ή ακόμα καλύτερα του source control. Ιδιαίτερα χρήσιμο επίσης και όταν υπάρχουν νέα μέλη στην ομάδα, αλλά και για τους παλιούς, γιατί όλους μας μπορεί να μας ξεφύγει κάτι κάποια στιγμή.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Ρε Παναγιώτη έλεος! Δεν είπα ότι δεν παίζει! Που το διάβασες αυτό στο μήνυμά μου? Είπα "καλό είναι" με τη λογική του ότι μπορεί να θέλεις να μεταφέρεις κώδικα από C# σε VB οπότε θα πρέπει να κάνεις χειροκίνητα αρκετή δουλειά. Και υπάρχουν περιπτώσεις (δες το link που έδωσα) που αυτή η τακτική δημιουργεί πρόβλημα. Επίσης, το _ convention γιατί λες ότι "δεν παίζει"?

---

Vir prudens non contra ventum mingit

Δεν είπες εσύ "δεν παίζει", ούτε εγώ είπα ότι κάτι από αυτά που λες δεν παίζει, εγώ είπα ότι το "_" γιατί εκείνη τη στιγμή δεν προλάβαινα να δοκιμάσω τον κώδικα και να δώ ότι το "_" όντως παίζει. Απομεινάρια της VB6 ... Όσο για το "καλό είναι", λέω ότι καλύτερα να ακολουθεί κανείς το convention της γλώσσας. Όσο για να μεταφέρεις κώδικα σε VB .... γιατί? Αφού άνετα μπορείς να χρησιμοποιήσεις ένα assembly σε C# από κώδικα σε VB.NET. Γιατί να το μετατρέψεις και να ξοδέψεις τόσο χρόνο για κάτι που είναι έτοιμο?

Το link που έδωσες το είδα αλλά αναφέρεται μόνο σε VB. Όσο γι αυτό που έκανε ο Palermo, έφτιαξε ουσιαστικά ΔΥΟ PROPERTIES οι οποίες διέφεραν μόνο στο case του πρώτου γράμματος. Το να βάλεις σε μία κλάση δύο properties που διαφέρουν μόνο στο casing είναι .... κακό. Το να έχεις ένα private field με μικρά για να αποθηκεύσει την τιμή ενός property με Camel case, δεν δημιουργεί κανένα πρόβλημα.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Θες να μεταφέρεις γιατί πολλές φορές έχεις ένα class library και σου λείπει ένα κομμάτι που βρίσκεις κάτι παρόμοιο στο internet σε άλλη όμως γλώσσα, οπότε δεν βάζεις ένα νέο project ίσα-ίσα γι αυτό το κομμάτι, το μετατρέπεις, το φέρνεις στα μέτρα σου και το βάζεις μαζί με το υπόλοιπο class library.

---

Vir prudens non contra ventum mingit

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

---

Don't try to argue with the machine
Elias Markelis
MCPD,MCT