Newsgroup: it.comp.lang.c++
Titolo: Convenzioni scrittura del codice!!!

Salve,
durante la spiegazione di prog. etc il mio prof ci ha illuminato con delle 
convenzioni usate per scrivere codice C++
es. il fatto che quando si dichiara una variabile composta da 2 nomi invece 
di mettere _ si inserisca la seconda o terza o x parola con la prima lettera 
in maiuscolo
(int cTemporanea, miaVariabile, restoDellaMiaDivisione etc.. etc... per fare 
degli esempi)
ora ricordo che lui aveva accennato anche a qualcos'altro riguardo classi 
etc le classi o gli oggetti venivano definiti con la prima lettera grande 
(es: class MiaClasse)
non ricordo proprio se era cosě :) cmq non sono riuscito a trovare + i suoi 
appunti (sempre che li abbia presi all'epoca) girovagando su internet e sui 
testi a mia disposizione non sono riuscito a trovare nemmeno nulla :)
Leggendo codice in giro per la rete ho visto svariati modi di scrivere...
So che il prof tiene tanto a quelle convenzioni quindi vi chiedo avete 
qualche link dove parli di queste convenzioni ?
Grazie anticipatamente
Rosario 

 qualche link dove parli di queste convenzioni ?
Le convenzioni sono *soggettive*!
Non esiste una convenzione standard per il C++ (meno male! :)
Ci sono quelli a cui piace lo stile del tuo professore, laMiaVariabile, 
ci sono quelli a cui invece piace usare tutto minuscolo e l'underscore: 
mia_variabile (es: la libreria standard STL _non_ usa la convenzione del 
tuo professore), ci sono quelli che fanno iniziare i nomi delle classi e 
dei metodi in maiuscolo, quelli che usano l'iniziale maiuscola solo per 
le classi, etc. etc.
Quelli che usano i tab a 4, a 8, a 2 caratteri...
Quelli che aprono la parentesi graffa su una linea a parte, e chi invece 
la apre sulla linea corrente:
if ( .... ) {
}
o
if ( .... ) 
{
}
etc. etc. :)
La cosa importante, credo, sia scegliere una convenzione, e non 
cambiarla durante lo sviluppo di un progetto.
Ciao,
Dan

 
Spero di essere stato d'aiuto
===
Gianni

 qualche link dove parli di queste convenzioni ?
Allegato al programma SharpDevelop c'è un documento pdf che parla di stili 
di programmazione (in c# però).
Visto che la parte che ti interessa non è specifica del linguaggio, ti 
includo (è corta) la parte sulle convenzioni dei nomi, sperando che ti vada 
bene:
//------------------------------------------------------------------------------------------------------------------
8 Naming Conventions
8.1 Capitalization Styles
8.1.1 Pascal Casing
This convention capitalizes the first character of each word (as in 
TestCounter).
8.1.2 Camel Casing
This convention capitalizes the first character of each word except the 
first one. E.g. testCounter.
8.1.3 Upper case
Only use all upper case for identifiers if it consists of an abbreviation 
which is one or two characters long,
identifiers of three or more characters should use Pascal Casing instead. 
For Example:
public class Math
{
public const PI = ...
public const E = ...
public const feigenBaumNumber = ...
}
8.2. Naming Guidelines
Generally the use of underscore characters inside names and naming according 
to the guidelines for
Hungarian notation are considered bad practice.
Hungarian notation is a defined set of pre and postfixes which are applied 
to names to reflect the type of the
variable. This style of naming was widely used in early Windows programming, 
but now is obsolete or at
least should be considered deprecated. Using Hungarian notation is not 
allowed if you follow this guide.
And remember: a good variable name describes the semantic not the type.
An exception to this rule is GUI code. All fields and variable names that 
contain GUI elements like button
should be postfixed with their type name without abbreviations. For example:
System.Windows.Forms.Button cancelButton;
System.Windows.Forms.TextBox nameTextBox;
8.2.1 Class Naming Guidelines
_ Class names must be nouns or noun phrases.
_ UsePascal Casing see 8.1.1
_ Do not use any class prefix
8.2.2 Interface Naming Guidelines
_ Name interfaces with nouns or noun phrases or adjectives describing 
behavior. (Example IComponent
or IEnumberable)
_ Use Pascal Casing (see 8.1.1)
_ Use I as prefix for the name, it is followed by a capital letter (first 
char of the interface name)
8.2.3 Enum Naming Guidelines
_ Use Pascal Casing for enum value names and enum type names
_ Don't prefix (or suffix) a enum type or enum values
_ Use singular names for enums
_ Use plural name for bit fields.
© Mike Krüger 2002 9
8.2.4 ReadOnly and Const Field Names
_ Name static fields with nouns, noun phrases or abbreviations for nouns
_ Use Pascal Casing (see 8.1.1)
8.2.5 Parameter/non const field Names
_ Do use descriptive names, which should be enough to determine the variable 
meaning and it's type. But
prefer a name that's based on the parameter's meaning.
_ Use Camel Casing (see 8.1.2)
8.2.6 Variable Names
_ Counting variables are preferably called i, j, k, l, m, n when used in 
'trivial' counting loops.
(see 10.2 for an example on more intelligent naming for global counters 
etc.)
_ Use Camel Casing (see 8.1.2)
8.2.7 Method Names
_ Name methods with verbs or verb phrases.
_ Use Pascal Casing (see 8.1.2)
8.2.8 Property Names
_ Name properties using nouns or noun phrases
_ Use Pascal Casing (see 8.1.2)
_ Consider naming a property with the same name as it's type
8.2.9 Event Names
_ Name event handlers with the EventHandler suffix.
_ Use two parameters named sender and e
_ Use Pascal Casing (see 8.1.1)
_ Name event argument classes with the EventArgs suffix.
_ Name event names that have a concept of pre and post using the present and 
past tense.
_ Consider naming events using a verb.
8.2.10 Capitalization summary
Type Case Notes
Class / Struct Pascal Casing
Interface Pascal Casing Starts with I
Enum values Pascal Casing
Enum type Pascal Casing
Events Pascal Casing
Exception class Pascal Casing End with Exception
public Fields Pascal Casing
Methods Pascal Casing
Namespace Pascal Casing
Property Pascal Casing
Protected/private Fields Camel Casing
Parameters Camel Casing
© Mike Krüger 2002

si infatti è proprio fissato...
io tanto per fare un esempio utilizzavo questo stile:
if(......)
{
.....
}
invece di :
if(......){
........
}
avevo imparato a programmare in quel modo in C e con la graffa sulla riga 
dell'if non mi veniva immediato capire dove iniziava il ciclo e dove finiva, 
ma lui, con le sue fissazioni, mi ha fatto cambiare modo.... ormai mi son 
abituato ad entrambi anche se utilizzo il secondo metodo (ormai è una cosa 
meccanica).
Altre convenzioni che ha spiegato non ricordo proprio, però devo trovarle 
per forza :) non mi va di perdere voti all'esame solo per quello.
E' un ragionamento sbagliato, a dire il vero ci son tante cose di sbagliate, 
purtroppo però fin quando non si finisce l'Università devi cercare di fare 
buon viso a cattivo gioco, cercherò tra i colleghi se qualcuno ha ancora 
quelle pagine dove spiegava le "sue" convenzioni.
Grazie di tutto
Ciao
Rosario 

 qualche link dove parli di queste convenzioni ?
Non credo ci sia uno standard sulle convenzioni, forse qualche cosa puoi 
trovare sul thinking in C++, ma non sono standard, sono suggerimenti 
dati dall'esperienza dell'autore (esperienza che ritengo comunque 
autorevole). Personalmente la mia convenzione č:
Le classi con la lettera maiuscola, es:
class MiaClasse {...};
I metodi con la prima minuscola e le altre maiuscole, es:
int MiaClasse::mioMetodo() {...}
le variabili con il carattere "_", es:
int mia_variabile;
La graffa sulla stessa riga e due spazi di rientro, es:
main() {
   for (int i=0; i<10; i++) {
     cout << i << endl;
   }
}
Questo per quanto mi riguarda. Poi, ripeto, standard non mi risulta ce 
ne siano, ciascuno faccia ciň che vuole tenendo presente che il codice 
viene piů letto che scritto, quindi un po' di clemenza verso chi deve 
leggerlo non guasta ^__^
Ciao!