Quanto male sta usando il carattere di sottolineatura nei nomi? [chiuso]

Question

Quanto male sta usando il carattere di sottolineatura nei nomi? [chiuso]

#1 da (6 voti)
#2 da (5 voti)

4

Sono principalmente un programmatore C. Nel mio mondo, scrivere likeThis o like_this è solo una questione di stile. In Haskell tuttavia, sembra che CamelCase sia la scelta definitiva. Personalmente, trovo il dopo molto più leggibile. Pensa a pthread_mutexattr_init rispetto a PthreadMutexAttrInit .

Cosa c'è di più, ho configurato vim per scambiare i numeri ei loro simboli alternativi (in C), dal momento che i numeri capita di essere scritto molto meno frequentemente di simboli come parentesi, stelle, commerciale, ecc, il che rende la vita più facile sul mio polso . Come bonus, questo mi consente di scrivere this_sort_of_thing senza utilizzare il tasto Maiusc.

La mia domanda è, dai programmatori Haskell, se usare il trattino basso nei nomi è accettabile o meno per la comunità di Haskell. CamelCase è una regola non scritta o una convenzione comune? Sarebbe ok per rendere le funzioni pubbliche likeThis ma internamente scrivere like_this ?

haskell

posta Shahbaz 08.07.2014 - 15:49

fonte

2 risposte

Leggi altre domande sui tag haskell

Esiste questo tipo di linguaggio di programmazione? I caratteri jolly nei generici di Java limitano o aumentano la flessibilità?

score 6 · Answer 1

Non c'è niente di particolarmente brutto nell'usare i caratteri di sottolineatura in Haskell. Una convenzione che ho visto è quella di usare underscore_case per i binding locali e camelCase per le funzioni di primo livello, o per prefissare i campi di un record con il nome del record e un carattere di sottolineatura:

data These a = These { these_fooBar, these_barBaz :: a }

Tuttavia, preferisco usare camelCase ovunque poiché non vale la pena di preoccuparsi, è la maggior parte del codice Haskell, ed è coerente con i nomi dei moduli e i costruttori, a meno che non ti piaccia This_Sort_of_Thing .

score 5 · Answer 2

Siamo conformi alle convenzioni e agli standard in modo che il nostro codice sia intuitivo per gli altri programmatori con cui lavorare.

private string _field;

public string Property { get; set; }

public void PublicMethod(string parameter)
{
    string localVariable;
}

private void privateMethod()
{

}

La maggior parte delle persone che sono state in un negozio di Microsoft per alcuni anni sarebbe molto familiare con questa convenzione.

Non avrei bisogno di mettere in discussione l'ambito di _appleCore o AppleCore; So che _appleCore è un campo privato e AppleCore è una proprietà pubblica.

Parte del tuo orgoglio come sviluppatore dovrebbe essere nella facilità con cui altre persone possono capire e lavorare con il tuo codice. Rendere il codice mantenibile e estensibile significa renderlo manutenibile / estensibile anche per le altre persone, non solo per noi stessi.

Per quanto riguarda la domanda su Haskall in particolare: link

Hanno linee guida, ma alla fine il proprietario della base di codice può definire la convenzione come qualsiasi cosa scelga, che non è molto aperta per discussioni o domande. Quindi, questa domanda che fai non può essere risolta definitivamente da noi.