Pourquoi les méthodes avec une seule instruction ont-elles besoin d'appareils d'accès?

Question

public void Finalise()
    ProcessFinalisation(true);

Ne compile pas, mais la version correcte:

public void Finalise()
{
    ProcessFinalisation(true);
}

Compile bien (bien sûr).

Si je suis autorisé, si sans supports, lorsque le code suivant n'a qu'une seule ligne:

if(true)
    CallMethod();

Pourquoi la même chose n'est-elle pas autorisée pour les méthodes avec une ligne suivante? Y a-t-il une raison technique?

Answer 1

Depuis C # 6.0, vous pouvez déclarer:

void WriteToConsole(string word) => Console.WriteLine(word)

Puis appelez ça comme d'habitude:

public static void Main()
{
    var word = "Hello World!";
    WriteToConsole(word);
}

Answer 2

La réponse évidente est la spécification linguistique; pour le raisonnement ... je suppose principalement de simplicité - cela ne valait tout simplement pas les frais généraux de vérifier la spécification des spécifications et du compilateur pour le minuscule petit Nombre de méthodes à instruction unique. En particulier, je peux potentiellement voir des problèmes avec les contraintes génériques, etc. (c'est-à-dire where T : IBlah, new() à la fin de la signature).

Notez que ne pas utiliser les accolades peut parfois conduire à des ambiguïtés et, à certains endroits, est mal vu. Je suis un peu plus pragmatique que cela personnellement, mais chacun à lui.

Il pourrait également être intéressant que C # à l'intérieur du rasoir ne permet pas de Utilisation sans accolades explicites. Du tout (c'est-à-dire même pour if etc).

Answer 3

Marc a fondamentalement raison. Pour développer un peu sa réponse: il y a un certain nombre d'endroits où C # nécessite un bloc de déclarations contrevenant plutôt que d'autoriser une instruction "nue". Elles sont:

• Le corps d'une méthode, d'un constructeur, d'un destructeur, d'un accessoire de propriété, d'un accessoire d'événement ou d'un accessoire d'indexeur.
• Le bloc d'essai, de capture, enfin, a vérifié, incontrôlé ou dangereux.
• le bloc d'une déclaration lambda ou la méthode anonyme
• Le bloc d'une instruction IF ou LOOP si le bloc contient directement une déclaration de variable locale. (C'est-à-dire: "Bien que (x! = 10) int y = 123;" est illégal; vous devez préparer la déclaration.)

Dans chacun de ces cas, il serait possible de proposer une grammaire sans ambiguïté (ou une heuristique pour désambiguïter une grammaire ambigu) pour la fonction où une seule déclaration non fractée est légale. Mais quel serait le point? Dans chacune de ces situations, vous vous attendez à voir plusieurs déclarations; Les déclarations uniques sont le cas rare et peu probable. Il semble que cela ne vaut pas vraiment la peine de rendre la grammaire sans ambiguïté pour ces cas très improbables.

Answer 4

Réponse courte: C # est stylisé après C, et C oblige les fonctions qui sont contredits en raison de la façon dont les déclarations de fonction C étaient.

Version longue avec histoire: De retour dans K&R C, les fonctions ont été déclarées comme ceci:

int function(arg1, arg2)
int arg1;
int arg2;
{ code }

Bien sûr, vous ne pouviez pas avoir des fonctions non frappées dans cet arrangement. ANSI C a mandaté la syntaxe que nous connaissons et aimons tous:

int function(int arg1, int arg2)
{ code }

mais ne permettait pas les fonctions non frappées, car elles provoqueraient des ravages avec des compilateurs plus anciens qui ne connaissaient que la syntaxe K&R [et la prise en charge des déclarations K&R était toujours nécessaire].

Le temps a continué, et des années plus tard, C # a été conçu autour de C [ou C ++, même différence en termes de syntaxe] et, puisque C n'a pas permis de fonctions non frappées, C # non plus.