Válka dvou jmenných konvencí v C#

Miroslav Holec

5. června. 2015 , aktualizace 29. března. 2016

Není snad rozporuplnější jmenná konvence v C# než privátní proměnné. Názory a argumenty se v této oblasti liší a vývojářská "obec" se dělí minimálně na dva velké tábory. Existuje správné řešení?

Problém

Abychom se dostali k problému, je důležité položit si otázku, proč jednoduše nepsat:

private int age;

Co vlastně nutí vývojáře používat alternativní jmenné konvence, jako například:

private int _age;
private int m_age;

Řada vývojářů na tento problém ani nemá názor a snaží se reflektovat nějakou autoritu.

Microsoft to má bez podtržíka, ReSharper má podtržítko a v kódu {autorita} jsem viděl {verze}, proto to taky tak dělám.

Problém je, že v této oblasti se liší i názory autorit. Pokud odmyslím šílenou maďarskou notaci m_whatever, vyvstává jednoduše otázka:

Psát privátní proměnné s podtržítkem nebo bez?

Zkuste si sami odpovědět na otázku, proč dát přednost verzi s podtržítkem. Nebo jinak: proč by měla verze bez podtržítka vadit?

This

Zdrojem většiny rozporů je lenost vývojářů v souvislosti s psaním klíčového slova this. Použije-li totiž vývojář verzi názvu proměnné bez podtržítka, pak musí použít v určitých případech i klíčové slovo this.

public class Service 
{
	private readonly Repository repository;

	public MyService(Repository repository)
	{
		this.repository = repository;
	}
}

public class Customer 
{
	private string firstname;

	public int Firstname {
        get { return this.firstname; }
        set { this.firstname = value; }
    }
}

Řešení

Měl bych k výše uvedeným dvěma příkladům, kterými přívrženci podtržítkové notace argumentují, drobné poznámky.

Od verze C# 3.0 (která je k dispozici asi 8 let) jsou k dispozici autoproperties, které nepotřebují k životu explicitně nakódované backing fields. Příklad nahoře je jednoduše možné přepsat už dlouhé roky jako:

public class Customer 
{
	public int Firstname { get; set; }
}

a potřeba podtržítka tak (většinou) odpadá.

Vyjímečně se setkávám s názorem, že private fields s podtržítkem jsou v kódu lépe vidět. Otázka je, zda je to vůbec potřeba. Pokud vývojář píše kód, potřebuje na první pohled vidět, zda je proměnná private nebo public? Obvykle se z cizí metody private proměnné ani v autocomplete nezobrazí (nemám-li např.: ReSharper).

V rámci upravované třídy je pro mě při psaní kódu viditelnost proměnné bezvýznamná, a pokud mám touhu zjistit více, stačí na ni najet myší a mohu si přečíst tooltip (k tomu jsou IDE).

Když si nejsem v budoucnu při psaní kódu jistý, zda je proměnná private nebo protected, dokonce se mi může stát, že budu muset zkusmo zadávat nejprve verzi bez podtržítka a poté z podtržítkem. Jinými slovy podtržítková notace snižuje použitelnost autocomplete. Podtržítková notace jednoduše nemá vestavěnou podporu ve Visual Studiu, zatímco this je podporováno přirozeně.

Názory autorit

Microsoft (především v poslední době) doporučuje nepoužívat podtržítkovou notaci a tuto konvenci přenáší i do nástroje StyleCop.

Doplněk ReSharper má ve standardním nastavení zatím podtržítkovou variantu, nicméně přidal jsem k produktu návrh na změnu této výchozí konvence a věřím, že s podporou dalších vývojářů brzy bude změněna.

Závěr

Podtržítková notace dle mého názoru způsobuje nekonzistenci kódu, zabraňuje efektivnímu použití autocomplete a znepřehledňuje jej. Co je ale snad nejdůležitější... v dnešním světě moudrého Visual Studia a řady jiných chytrých rozšíření nepřináší vůbec žádnou výhodu.

TOP Termíny školení

ASP.NET Core se dočkal již své třetí verze a nabízí řadu možností pro vývoj webových aplikací a služeb. I v roce 2020 mám vypsané termíny na nejrůznější témata od základů .NET Core přes vývoj REST API až po mikroslužby pomocí gRPC.