Non importa quanto ami un linguaggio di programmazione, ci sono sempre alcuni dettagli che non sono così belli come potrebbero essere.

In questa domanda, vorrei concentrarmi specificamente sugli elementi di sintassi. In un linguaggio di programmazione che usi frequentemente (forse il tuo linguaggio di programmazione preferito, o forse quello che sei costretto a usare al lavoro), quale elemento di sintassi trovi più illeggibile, poco chiaro, scomodo o spiacevole?

Inserimento punto e virgola in JavaScript.

Non mi è mai stato morso spesso, ma è un'idea così fenomenale che mi fa girare la testa.

Ecco le regole (da ECMA-262 Sezione 7.9)

1. Quando il programma contiene un token che non è consentito dalla grammatica formale, viene inserito un punto e virgola se (a) c'è un'interruzione di linea in quel punto, o (b) il token imprevisto era un controvento di chiusura.
2. Quando viene raggiunta la fine di un file, se il programma non può essere analizzato diversamente, viene inserito un punto e virgola.
3. Quando viene rilevata una "produzione limitata" e contiene un terminatore di riga in un punto in cui la grammatica contiene l'annotazione "[nessun LineTerminator qui]", viene inserito un punto e virgola.

Esempio:

return 1; // returns 1

return
1; // returns undefined

Sintassi del bean Java a causa della mancanza di proprietà C #

/**
 * Name of user
 */
private String name;

/**
 * Gets name of user
 * @return Name of user
 */
public String getName() {
    return this.name;
}

/**
 * Sets name of user. 
 * @param name
 */
public void setName(final String name) {
    this.name = name;
}

GAH !!!

Problemi che ho con questo

• Troppo codice - Avere un campo documentato, un metodo getter documentato e un metodo setter documentato. Questo esempio estremamente semplice ha 20 righe di codice per una singola proprietà
• Elenchi di metodi Clutters - "Fammi trovare quel metodo, mano su:getX , getY, getZ, getAnotherAnnoyingField, getWhyIHateJavaBeans, getThisIsVerbose, getGAH... ah eccolo, hashCode.
• Molteplici aree di documentazione portano a documentazione scadente, obsoleta o mancante : fastidioso quando si cerca di capire cosa fa il codice
• Quindi una fastidiosa terza parte ha dovuto inventare un plugin per farlo facilmente - Spoon , Shark , tra gli altri.

Sensibilità agli spazi bianchi.

Python mi infastidisce in questo senso. Voglio dire, rientro correttamente comunque, ma mi dà fastidio che avrei dovuto . Rendere la presentazione parte della sintassi mi irrita.

La switchdichiarazione (in C, C ++, C #, Java, ecc.)

Ecco un esempio del perché lo trovo estremamente scomodo:

switch (someVariable)
{
    case 1:
        int i = something();
        doSomething(i);
        break;

    case 2:
        int i = somethingElse();
        doSomethingElse(i);
        break;
}

Questo non viene compilato perché la variabile iviene rideclared nello stesso ambito. Sembra un dettaglio minore, ma mi morde molto spesso. Posso aggiungere parentesi graffe per mitigarlo, ma sarebbe bello se le parentesi graffe fossero state parte obbligatoria della sintassi e non vi fosse alcun livello di ridondanza aggiuntivo ridondante. Odio anche dover scrivere un extra break. Questo sarebbe molto più bello:

switch (someVariable)
case 1
{
    int i = something();
    doSomething(i);
}
case 2
{
    int i = somethingElse();
    doSomethingElse(i);
}
default
{
    ...
}

Questo lo rende più simile a una if/ elsecatena, il che è una buona cosa perché è anche semanticamente simile. Almeno in C # non sarebbe comunque la stessa cosa, perché in una switchdichiarazione l'ordine delle etichette del caso non ha importanza, ma in un if/ elselo fa.

Dichiarazioni di array in VB.NET

Riesco sempre a dimenticare che quando si inizializzano array fissi in VB.NET, si specifica il limite superiore dell'array e non il numero di elementi come in C / C ++, PHP o Java. Oltre a VB6 (non andremo lì ...), non riesco a pensare a un'altra lingua che lo fa in questo modo:

Dim myArray(20) as Integer  '# Creates an array with 21 elements,
                            '# indexed from 0 to 20

VB6 - Dichiarazione e assegnazione variabili separate

La maggior parte delle lingue ti consente di dichiarare una variabile e assegnarla in una riga di codice; VB6, d'altra parte, ti costringe a usarne due.

Dim i as Integer
i = 0

Dim derpderp as Collection
Set derpderp = new Collection

È possibile utilizzare i due punti per inserire due comandi su una riga, ma diventa rapidamente disordinato nel codice reale.

Dim i as Integer: i = 0
Dim derpderp as Collection: Set derpderp = new Collection

Commentando in CSS

//non commenta righe di codice come in molte altre lingue, come PHP e Javascript. Anche se /* this is commented out */funziona, preferisco usare// .

È un fastidio, perché la metà delle volte mi dimentico che sto modificando CSS e quindi devo tornare indietro e correggere l'errore.

PHP - ordinamento coerente degli argomenti

PHP ha una serie di utili funzioni per eseguire praticamente ogni operazione che si possa pensare su un array o una stringa. Molte di queste operazioni richiedono l'utilizzo sia di una $needleche di una $haystack, ma funzioni diverse le portano in ordini diversi. Quale funzione richiede quali argomenti sono uno di quei fatti che il mio cervello rifiuta di assorbire, non importa quante volte li incontro!

Prendi le funzioni in_array e strstr :

// Check whether $needle occurs in array $haystack
bool in_array (mixed $needle, array $haystack [, bool $strict])

// Check whether $needle is a substring of $haystack
string strstr (string $haystack, mixed $needle [, bool $before_needle=false])

Stranamente, PHP sembra essere internamente coerente con questi ordinamenti in quanto tutte le funzioni di stringa sembrano usare $haystack, $needlementre le funzioni di matrice sono il contrario, ma questo può richiedere un po 'di tempo per abituarsi a qualcuno che non conosce PHP. C'è un buon post su ExpressionEngine che parla di questa particolare stranezza in modo più dettagliato, così come una discussione sulla lista dei bug di PHP , che presenta una risposta molto breve da parte del team PHP!

helly@php.net
Usa quindi un IDE decente.

Pitone

self parametro nelle definizioni del metodo di istanza

Giava

Periodo. Punto. Fine della storia.

Dove iniziare? Oh, so da dove cominciare: i generici follemente complicati, brutti, stupidi e intrinsecamente rotti . Devo aggiungere altro? :( Va bene, quindi: digita cancellazione .

Quindi c'è una gestione delle risorse non deterministica. Kewl feetcher!

Qual è il prossimo passo? Oh sì: le stupide regex di Java sono la mia carne più irritante e ribollente. Non riesco a contare quante volte sono stato colpito dal fatto che non ho abbastanza barre rovesciate. Questo è anche peggio che non avere accesso a nessuna proprietà Unicode di questo millennio - che è un toro completo. Dieci anni da baraccone fuori moda !!!Completamente inutile. Trash it.

Quindi c'è il bug che le scorciatoie della classe di caratteri non funzionano su non ASCII. Che dolore reale! E non considerare nemmeno l'utilizzo\p{javaWhiteSpace} ; non fa la cosa giusta con diversi punti di codice di spazi bianchi Unicode molto comuni.

Sapevi che c'è una \p{javaJavaIdentifierStart}proprietà? Che cosa stavano pensando? Sono così contento di aver fatto sbirciare così furbi su questo disco.

Hai mai provato a usare il flag CANON_EQ? Lo sai che lo fa davvero e cosa non fa? Che ne dici del cosiddetto "caso Unicode"? Un sacco di cose normali del case non funzionano affatto.

Quindi rendono difficile scrivere regex mantenibili. Java non ha ancora capito come scrivere stringhe multilinea, quindi finisci per scrivere cose folli come questa:

    "(?= ^ [A-Z] [A-Za-z0-9\\-] + $)      \n"
  + "(?! ^ .*                             \n"
  + "    (?: ^     \\d+      $            \n"
  + "      | ^ [A-Z] - [A-Z] $            \n"
  + "      | Invitrogen                   \n"
  + "      | Clontech                     \n"
  + "      | L-L-X-X                      \n"
  + "      | Sarstedt                     \n"
  + "      | Roche                        \n"
  + "      | Beckman                      \n"
  + "      | Bayer                        \n"
  + "    )      # end alternatives        \n"
  + ")          # end negated lookahead   \n" 

Cosa sono tutte quelle nuove linee? Oh, solo stupidità di Java. Hanno usato commenti Perl, non commenti Java ( idioti! ) Che vanno fino alla fine della riga. Quindi se non li metti\n lì, taglia il resto del tuo schema. Duh e double duh!

Non usare regex in Java: finirai per voler distruggere le cose, è tutto così doloroso e rotto. Non posso credere che la gente lo sopporti. Alcuni no .

Quindi possiamo iniziare a parlare dell'assurdità idiota di Java con le codifiche. Innanzitutto, c'è il fatto che la codifica della piattaforma predefinita è sempre una codifica a 8 bit scadente anche se i charchar di Java sono Unicode. Quindi c'è come non generano un'eccezione su un errore di codifica. Ti garantirai una merda. O che ne dici di questo:

OutputStreamWriter(OutputStream out) 
          Creates an OutputStreamWriter that uses the default character encoding.
OutputStreamWriter(OutputStream out, Charset cs) 
          Creates an OutputStreamWriter that uses the given charset.
OutputStreamWriter(OutputStream out, CharsetEncoder enc) 
          Creates an OutputStreamWriter that uses the given charset encoder.
OutputStreamWriter(OutputStream out, String charsetName) 
          Creates an OutputStreamWriter that uses the named charset.

Qual è la differenza? Lo sapevi solo uno di questi genererà un'eccezione se si verifica un errore di codifica? Il resto li mette solo a museruola.

Poi c'è l'idiozia dei caratteri Java che non sono sufficienti per contenere un personaggio! A che diavolo stanno pensando? Ecco perché li chiamo charchars. Devi scrivere codice in questo modo se ti aspetti che funzioni correttamente:

private static void say_physical(String s) { 
    System.out.print("U+");
    for (int i = 0; i < s.length(); i++) {
        System.out.printf("%X", s.codePointAt(i));
        if (s.codePointAt(i) > Character.MAX_VALUE) { i++; }  // UG!
        if (i+1 < s.length()) { System.out.printf("."); }
    }
}

E chi mai pensa di farlo? Accanto a nessuno.

In quanti personaggi ci sono "\uD83D\uDCA9"? Uno o due? Dipende da come li conti. Il motore regex si occupa ovviamente dei caratteri logici, quindi un modello ^.$avrà successo e un modello ^..$fallirà. Questa follia è dimostrata qui:

String { U+61, "\u0061", "a" }  =~ /^.$/ => matched.
String { U+61, "\u0061", "a" }  =~ /^..$/ => failed.
String { U+61.61, "\u0061\u0061", "aa" }  =~ /^.$/ => failed.
String { U+61.61, "\u0061\u0061", "aa" }  =~ /^..$/ => matched.
String { U+DF, "\u00DF", "ß" }  =~ /^.$/ => matched.
String { U+DF, "\u00DF", "ß" }  =~ /^..$/ => failed.
String { U+DF.DF, "\u00DF\u00DF", "ßß" }  =~ /^.$/ => failed.
String { U+DF.DF, "\u00DF\u00DF", "ßß" }  =~ /^..$/ => matched.
String { U+3C3, "\u03C3", "σ" }  =~ /^.$/ => matched.
String { U+3C3, "\u03C3", "σ" }  =~ /^..$/ => failed.
String { U+3C3.3C3, "\u03C3\u03C3", "σσ" }  =~ /^.$/ => failed.
String { U+3C3.3C3, "\u03C3\u03C3", "σσ" }  =~ /^..$/ => matched.
String { U+1F4A9, "\uD83D\uDCA9", "💩" }  =~ /^.$/ => matched.
String { U+1F4A9, "\uD83D\uDCA9", "💩" }  =~ /^..$/ => failed.
String { U+1F4A9.1F4A9, "\uD83D\uDCA9\uD83D\uDCA9", "💩💩" }  =~ /^.$/ => failed.
String { U+1F4A9.1F4A9, "\uD83D\uDCA9\uD83D\uDCA9", "💩💩" }  =~ /^..$/ => matched.

Quell'idiota è tutto perché non puoi scrivere il perfettamente ragionevole \u1F4A9 , e naturalmente non ricevi alcun avviso sul fatto che non puoi farlo. Fa solo la cosa sbagliata.

Stoooopid.

Mentre ci siamo, l'intera \uXXXXnotazione è congenitamente cerebrale. Il preprocessore Java ( sì, mi hai sentito ) ci arriva prima che lo faccia Java, quindi ti è proibito scrivere cose perfettamente ragionevoli come "\u0022", perché quando Java lo vede, il suo preprocessore lo ha trasformato """, quindi perdi. Oh aspetta, non se è in una regex! Quindi puoi usare"\\u0022" bene.

Riiiiiiiight!

Sapevi che in Java non c'è modo di farlo isatty(0) chiamata? Non ti è nemmeno permesso di pensare tali pensieri. Non ti farebbe bene.

E poi c'è l'intero abominio del sentiero di classe.

O il fatto che non c'è modo di specificare la codifica del file sorgente Java nello stesso file sorgente in modo da non perderlo? Ancora una volta chiedo di sapere: COSA PENSANO L'INFERNO?

Ferma la follia! Non riesco a credere che la gente sopporti questa spazzatura. È uno scherzo completo. Preferirei essere un salutista Walmart piuttosto che subire le imbragature e le frecce della folle follia di Java. È tutto rotto e non solo non possono ripararlo, non lo ripareranno.

Questo dalle stesse persone volgari che si vantavano di un linguaggio che rendeva illegale avere una printf()funzione. Accidenti, quello certo ha funzionato davvero bene, non è vero però !?

Teschi di numeri. Gli schiaffi sono troppo gentili per loro. Se volessi programmare in assembler, lo farei. Questo non è un linguaggio salvabile. L'imperatore è nudo.

Lo odiamo. Lo odiamo per sempre . Lascialo morire muori muori !

Sintassi della dichiarazione del puntatore a funzione in C e C ++:

(int)(*f)(int, int);

Che dichiara un puntatore a funzione chiamato il fcui punta può richiedere due intsecondi e restituire un int.

Preferirei di gran lunga una sintassi come questa:

f: (int, int) => int

Supponiamo che tu voglia dichiarare un puntatore a funzione la gcui punta può prendere due se intuna funzione da inte inta int, e restituire un int.

Con la notazione C o C ++, la dichiareresti come:

(int)(*g)(int, int, int(int, int));

Con la notazione sopra proposta la stessa cosa può essere dichiarata come:

g: (int, int, (int, int) => int) => int

Ultimamente l'IMO è molto più intuitivo.

A parte: il linguaggio di programmazione chiamato OOC risolve questa sintassi (e vari altri problemi sintattici in C e C ++). Dai un'occhiata alla sua homepage qui .

Verbosità in Java.

vale a dire:

public static final int 

Sintassi dello spazio dei nomi \ we \ wouldnt \ fix \ our \ parser in PHP

La sintassi non è solo brutta, porta alla confusione quando i nuovi sviluppatori devono pensare agli spazi dei nomi nelle stringhe. (PHP interpola le barre rovesciate in stringhe tra virgolette doppie come sequenze di escape. Cercare di rappresentare uno spazio dei nomi come \you\should\never\do\thatin una stringa tra virgolette doppie anziché in una stringa tra virgolette singole porta a nuove righe, tabulazioni e disastri.)

Disprezzo il fatto che le parentesi graffe possano essere opzionali dopo un'istruzione if / while / for.

Soprattutto quando vedo codice come,

if (...)
    for(...)
        ... One line of stuff ...

Per favore, metti le parentesi graffe e finiscila.

VBScript non ha operatori logici

A differenza di quasi tutti i linguaggi sensibili, VBScript utilizza operatori bit per bit anziché operatori logici. Cosa significa in pratica? Bene, come sottolinea Eric Lippert :

If Blah = True Then Print "True!" Else Print "False!"

e

If Blah Then Print "True!" Else Print "False!"

NON sono gli stessi in VBScript!

Ancora peggio, tuttavia, ciò significa che non esiste una valutazione di cortocircuito in VBScript in modo che la seguente istruzione arresti il programma in modo anomalo se BlahèNothing

If (Not Blah Is Nothing) And (Blah.Frob = 123) Then
...

Esatto, VBScript valuterà entrambe le parti del confronto AND, anche se il primo è falso! Lascia che affondi quel ...

EDIT: dopo la discussione nei commenti ho deciso di aggiornare questa risposta per spiegarmi meglio.

Odio davvero il modo in cui i puntatori a funzione appaiono in C. Di solito qualsiasi dichiarazione di variabile sembra una tupla di: type varname; Le dichiarazioni dei puntatori a funzione invece sembrano una dichiarazione della funzione con * prima del nome della funzione. Posso accettarlo come descrizione di un tipo di puntatore, ma in C questo dichiara sia il tipo che il nome di una variabile di quel tipo. Questo mi sembra incoerente perché le dichiarazioni dei tipi sono altrimenti distinte dalle dichiarazioni delle variabili. struct myStruct{int X; int Y;}definisce solo un tipo, non definisce una variabile denominata myStruct. Allo stesso modo non vedo alcun motivo per raggruppare le dichiarazioni di tipo e le dichiarazioni di variabili in un'unica istruzione atomica in puntatori a funzione, né apprezzo la deviazione daltype varname; struttura.

Qualcuno ha sottolineato che è coerente con qualche regola a spirale, e potrebbe essere il caso, ma il segno di una buona sintassi è che si spiega da sé e la sua logica interna è ovvia. La regola della spirale non è affatto ovvia.

Punto e virgola in VBScript - o la loro mancanza

Passo tutto il giorno a lavorare in lingue che prevedono punti e virgola alla fine di ogni riga. Aggiungine uno alla fine della riga in VBScript e il tuo codice non verrà più eseguito.

Argomenti in / out. Sono tutto per argomenti (per fortuna lo sono), anche gli argomenti vanno bene, ma un argomento che deve trasmettere questi due stati mi fa incazzare.

Quello che mi rivolgo qui sono funzioni che prendono l'input da un parametro e poi lo sovrascrivono con un po 'di output. Va bene passare un oggetto per riferimento per aggiornarlo. Ma, soprattutto per i tipi primitivi, prendere un oggetto, usarlo, quindi cambiarlo completamente, non è giusto per me. Non dovresti cambiare il significato dell'argomento attraverso un inout.

Dichiarazioni di array in C e C ++.

In genere, una dichiarazione variabile è del formato type variable_name. Puoi facilmente leggere quelle dichiarazioni in modo da sinistra a destra. Ma int foo[size]dapprima sembra che stia dichiarando foocome un int, e poi leggi più avanti e vedi che il foo è di tipo "array di numeri interi". int[size] foolegge molto meglio.

E ho anche odio quando i programmatori dichiarano puntatori come questo per un motivo simile: int *foo. Per qualche motivo non l'ho capito, è il modo tipico in cui è scritto.

Parametrizzazione ridondante in Java:

HashMap<String,HashMap<String,String>> foo = new HashMap<String, HashMap<String, String>>();

Quale altra parametrizzazione di tipo pensa foo possa avere il compilatore ?

Dato che le persone si sono già lamentate di =vs. ==, vorrei far notare un'alternativa molto peggiore. PL / Avevo entrambi :=e =, ma quando qualcosa era "ovviamente" un compito, ti avrebbe permesso di cavartela =per farlo. utilizzando:= ti permetti di forzare qualcosa ad essere un compito in una situazione in cui il compilatore lo interpreterebbe come un confronto.

Sfortunatamente, il compilatore non ha sempre deciso le cose esattamente come ci si potrebbe aspettare. Considera solo un esempio ovvio:

A = B = 0;

Ora, per la maggior parte delle persone che hanno familiarità con la maggior parte delle lingue "ordinarie", il significato di questo è abbastanza ovvio: assegnare 0 sia a A che a B. PL / I è solo un po '... diverso. Per ragioni note solo ai (folli) designer del linguaggio, il primo =viene interpretato come un incarico, ma il secondo= viene interpretato come un confronto. Pertanto, questo confronta B su 0 e quindi assegna il risultato di quel confronto ad A (seguendo la convenzione di tipo C che "falso" risulta in 0 e "vero" in 1).

Quindi, se B era 0, allora A diventa 1. Altrimenti, A diventa 0. In altre parole, invece di assegnare lo stesso valore ad A e B, questo in realtà garantisce che A non possa avere lo stesso valore di B.

In conclusione: anche se lo stile C / C ++ / PHP inizialmente sembra un dolore, l'alternativa è molto peggio ¹ .

¹ Beh, tecnicamente, c'è un'altra alternativa: lo stile Pascal, dove =sempre il confronto e l'assegnazione richiedono sempre :=. Dopo averlo usato per un po ', è abbastanza ovvio (almeno per me) che il compito è abbastanza più comune del confronto che se hai bisogno di "cose" extra per chiarire le due cose, dovresti sicuramente mantenere i compiti puliti e semplici e richiede il "grunge" extra sui confronti, non viceversa.

Perl

1. Vorrei che Perl mi lasciasse scrivere if($x < 10) do_something();. Al momento, devi scriverlo come uno do_something() if($x < 10);o l'altro if($x < 10) { do_something(); }.

reinterpret_cast<unsigned long>in c ++. Questa operazione è utile nel trattare con API straniere e garantire precisione numerica, perché dovrebbe essere un tale dolore da digitare e così brutto da guardare?

Il costrutto for ... in in JavaScript e il costrutto foreach in PHP quando si esegue il loop su array. Entrambi facilitano la scrittura di bug rispetto al codice corretto.

Puntatori di matrici o matrici di puntatori in C / C ++. Sono ancora confuso su questi.

Il fatto che Python si basi sulla formattazione del testo.

Javascript / Java ecc., Uguale a confronto, ad es. Se (a == 1)

Quante volte scrivo if (a = 1)?

Da umano l'ho letto perfettamente. Ma l'interprete / compilatore maledetto dice "Ehi, assegnerò 1 a a, quindi verificherò se a è uguale a 1 e ci crederesti che sì!

Mi fa salire il muro.

se (a == 1) è molto meno leggibile e l'interprete / compilatore dovrebbe sapere comunque cosa intendo; molte altre lingue minori (VB) hanno funzionato con successo per centinaia di anni.

Verbosità nelle classi anonime Java. Speriamo di essere risolto presto.

structPointer->memberin C / C ++. Può essere utile per leggere il codice di qualcun altro, ma non mi piace. Due personaggi invece di uno ... che spreco di spazio!

Il codice multilinea Scala tra parentesi

Per esempio:

class Foo(
         val bar: String,
         val baz: Int,
         val bing: String,
         val bong: Boolean
 ) extends Model {
   // body here
 }

Ciò che effettivamente ottieni da esso è eccezionale. Genera il costruttore, i getter e i setter per te. Ma è sicuramente brutto e rompe tutti i miei modelli mentali su come indentare il codice e sostanzialmente mi fa sentire come se fossi in una sorta di bizzarro sandwich con Java da un lato e Lisp dall'altro. (Oh, aspetta ... questo è piuttosto il punto della Scala.)