ReSharper és StyleCop kontra lelépési szabály (tiszta kód)

Bármilyen kódolási szabvány mellett szívesen dolgozom, de nehezen tudom összeegyeztetni ezt a megközelítést a tiszta kód írásával, elsősorban azért, mert szigorúan betartom a lelépési szabályt (Robert C Martin – Clean Code), és Az abc-sorolás megtöri azt.

A lelépési szabály leírása a következő:

Szeretnénk, ha a kód felülről lefelé haladó narratívaként olvasható. Szeretnénk, ha minden függvényt követnének az absztrakció következő szintjén lévők, hogy a függvények listáját leolvasva egy absztrakciós szintről lefelé tudjunk olvasni a programot. Ezt nevezem lelépési szabálynak. Egy függvény argumentumainak ideális száma nulla. Következik egy. Aztán kettő. A három érvet lehetőleg kerülni kell.

Ezt a megközelítést követve a következő (kitalált) kódot írhatom:

public class Processor
{
    public Processor(ProcessData data)
    {
        Configure(data);
    }


    public void Configure(ProcessData data)
    {
        ClearState();
        UnpackData();
        ProcessData();
        TransformData();
        PostProcessData();
    }

    private void ClearState() { /*Snip*/ }

    private void UnpackData() { /*Snip*/ }

    private void ProcessData() { /*Snip*/ }

    private void TransformData() { /*Snip*/ }

    private void PostProcessData() { /*Snip*/ }


    public IEnumerable<GroupedRecordSet> AggregateRecords(IEnumerable<Record> records)
    {
        var groups = CalculateGrouping(records);
        PopulateGroups(groups, records);
        return groups;
    }

    private IEnumerable<GroupedRecordSet> CalculateGrouping(IEnumerable<Record> records) { /*snip*/ }

    private void PopulateGroups(IEnumerable<GroupedRecordSet> groups, IEnumerable<Record> records) { /*snip*/ }
}

Aztán az automatikus formázás futtatásakor a következőket nézem (a megjegyzések eltávolítva):

public class Processor
{
    #region Constructors and Destructors

    public Processor(ProcessData data)
    {
        Configure(data);
    }

    #endregion

    #region Public Methods and Operators

    public IEnumerable<GroupedRecordSet> AggregateRecords(IEnumerable<Record> records)
    {
        var groups = this.CalculateGrouping(records);
        this.PopulateGroups(groups, records);
        return groups;
    }

    public void Configure(ProcessData data)
    {
        this.ClearState();
        this.UnpackData();
        this.ProcessData();
        this.TransformData();
        this.PostProcessData();
    }

    #endregion

    #region Methods

    private IEnumerable<GroupedRecordSet> CalculateGrouping(IEnumerable<Record> records) { /*snip*/ }

    private void ClearState() { /*snip*/ }

    private void PopulateGroups(IEnumerable<GroupedRecordSet> groups, IEnumerable<Record> records) { /*snip*/ }

    private void PostProcessData() { /*snip*/ }

    private void ProcessData() { /*snip*/ }

    private void TransformData() { /*snip*/ }

    private void UnpackData() { /*snip*/ }

    #endregion
}

A második stílust most egy pillantásra sokkal nehezebb megérteni, és azon kapom magam, hogy szokatlanul sok mindent meg kell őriznem az első stílus olvashatóságának megőrzése érdekében, a második korlátain belül. Ezek tartalmazzák:

• Tulajdonos metódusnév előtagja – azaz ConfigureClearState, ConfigureUnpackData, AggregateRecordsCalculateGroupings, AggregateRecordsPopulateGroups stb. Ez hosszú tagnevekhez vezet, különösen, ha a 'owner' metódusok további saját metódusokat igényelnek.
• Defaktorálás – a kód áthelyezése kis metódusokból, amelyeket eredetileg újra faktoráltam, vissza arra a metódusra, ahonnan jött. Ami hosszú módszerekhez vezet.
• Részleges osztályok – Igazából még nem jutottam el idáig, de teljesen lehetséges, hogy a kapcsolódó metódusokat részleges osztályokba fogom helyezni, hogy elkülönüljenek a fő kódtörzstől. Ami megtölti a megoldásböngészőt kódfájlok halomával.

Nyilvánvalóan nem vagyok elégedett ezen megközelítések egyikével sem, de amennyire én látom, ez az egyetlen igazi lehetőség az olvashatóság fenntartására a működési paramétereken belül.

Úgy tűnik, a második megközelítés a Microsoft house stílusa, így azt hiszem, a kérdésem(ek) a következők lennének:

• Helyes, hogy a második megközelítés a Microsoft ház stílusa?
• Ha igen, hogyan tartja fenn a Microsoft tiszta olvasható kódot a második stílusban?
• Találkozott már valaki ezzel az eltéréssel, és milyen megközelítéseket alkalmaztak az emberek a jó olvashatóság elérése érdekében?
• Melyek a tiszta kód írásának általános stíluspreferenciái?