COVID-19: Všechna školení nyní i on-line. Přečtěte si mé tipy na vzdělávání v době koronavirové.
Slovenská verzeSlovensky

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

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í?

Miroslav Holec

Miroslav Holec

5. června. 2015
upraven 29. března. 2016

Tento článek je již velmi zastaralý. Zastaralé články nemusí popisovat aktuální stav technologií, nejideálnější řešení a můj aktuální pohled na danou technologii.

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.


👨‍🎓 Webináře pro vývojáře - nyní zdarma

Vzdělávat se můžete i z pohodlí domova. Klasická školení jsem doplnil o související témata, která si můžete poslechnout v podobě živých webinářů. Přidejte se téměř 200 vývojářům, kteří se již připojili k mým webinářům!

Termín Místo
🍀 Software a nástroje, které používám 6. října 2020 online více
🍀 Co ještě nevíte o middlewares 9. října 2020 online více
🍀 Blazor Server 16. října 2020 online více
🍀 Novinky v .NET 5 pro REST API 21. října 2020 online více
Loading