Commentando le strategie in C # e asp.net web api

1

Ho lavorato a un progetto ASP.NET Web Api 2 come esercizio di apprendimento e mi chiedevo quale fosse la norma riguardante i commenti.

Uso il modello di repository / servizio, e tutto è molto disaccoppiato, il che si traduce nell'avere un gran numero di classi il cui scopo è abbastanza chiaro. Do anche un nome alle mie variabili in un modo che si spiegano da sole.

Questo mi fa pensare a cosa dovrei effettivamente commentare in questo scenario.

  • Dovrei limitarmi ai riassunti delle classi (anche se la classe stessa è auto-esplicativa)?
  • Per quanto riguarda i metodi auto-esplicativi?
  • Le classi di dati / entità aziendali richiedono un riepilogo?
  • E riguardo le interfacce?

Per dare un po 'più di contesto, ecco una delle mie classi di repository che fornisce funzionalità CRUD:

public class UserRepository : RepositoryBase<User, decimal>
{
    private readonly ShortStuffContext _context;

    public UserRepository(ShortStuffContext context)
    {
        _context = context;
    }

    public override IEnumerable<User> GetAll()
    {
        return _context.Users.BuildUser();
    }

    public override User GetById(decimal id)
    {
        return _context.Users.FirstOrDefault(u => u.Id == id).BuildUser();
    }

    public override CreateStatus<decimal> Create(User entity)
    {
        if (_context.Users.Any(u => u.Id == entity.Id))
        {
            return new CreateStatus<decimal> { status = CreateStatusEnum.Conflict };
        }

        var user = new Data.Entities.User();
        user.InjectFrom<SmartConventionInjection>(entity);
        _context.Users.Add(user);
        _context.SaveChanges();

        return new CreateStatus<decimal> { status = CreateStatusEnum.Created, Id = user.Id };
    }

    public override UpdateStatus Update(User entity)
    {
        var dbUser = _context.Users.FirstOrDefault(u => u.Id == entity.Id)
                             .InjectFrom<NotNullInjection>(entity);

        if (dbUser != null)
        {
            var changeTrackerUser = _context.ChangeTracker.Entries<Data.Entities.User>()
                            .FirstOrDefault(u => u.Entity.Id == entity.Id);

            changeTrackerUser.CurrentValues.SetValues(dbUser);
            if (_context.SaveChanges() == 0)
            {
                return UpdateStatus.NoChange;
            }
            return UpdateStatus.Updated;
        }
        return UpdateStatus.NotFound;
    }

    public override void Delete(decimal id)
    {
        var user = _context.Users.FirstOrDefault(u => u.Id == id);
        _context.Users.Remove(user);
        _context.SaveChanges();
    }
}

Quindi, in una classe come questa, vale la pena inserire un riassunto come "Fornisce funzionalità CRUD per l'Entità dati utente" (e poi ripetere quel sommario per ogni altro repository) o no? Che dire dei commenti sui metodi o dei commenti in linea?

Modifica: il mio progetto è su Github . So di aggiungere commenti a metodi più complessi e sto pianificando di aggiungere presto commenti alle estensioni e alle classi ValueInjecter (che contengono di gran lunga il codice più complesso). Oltre a ciò, qualsiasi consiglio su dove inserire commenti è molto gradito.

    
posta Bio2hazard 05.07.2014 - 00:28
fonte

3 risposte

3

Non c'è una risposta definitiva: alcune persone saranno inclini ad aggiungere commenti ad ogni classe e metodo; altri cercheranno di evitare di commentare cose che sono già abbastanza esplicite.

  • Se segui le regole predefinite di StyleCop, devi commentare ogni membro , compresi i campi privati. Potresti voler sopprimere gli avvertimenti se il codice è veramente ripetitivo. Ma se lo è, potresti chiederti perché non viene generato automaticamente (nota: il codice generato automaticamente è contrassegnato in modo specifico e non viene elaborato da StyleCop).

  • Se non lo fai, sentiti libero di commentare il più o il meno che ritieni appropriato . Se avessi mantenuto il codice dalla tua domanda, avrei aggiunto commenti su ogni metodo, solo per semplificare il mio lavoro più tardi: preferirei leggere una frase in un suggerimento in Visual Studio piuttosto che cercare di indovinare il significato di il metodo. D'altra parte, eviterei di commentare qualcosa come Title proprietà della classe Product .

In tutti i casi, prova a portare qualcosa di utile in quei commenti , non solo ripetere il nome del metodo o della proprietà. Ad esempio, se la classe Product ha una proprietà Description , un modo è scrivere:

/// <summary>
/// Gets the description of the product.
/// </summary>

Questo commento non porta nulla di utile. Un'altra possibilità è questa:

/// <summary>
/// Gets the piece of text which is displayed publicly and is usually written by the
/// managers. The description is localized for the current user.
/// </summary>

Ecco qui tre informazioni utili:

  • La descrizione è pubblica. L'app web può anche avere un campo di riepilogo interno in cui i gestori possono scrivere testo da soli.

  • La descrizione viene solitamente scritta dai gestori. Ciò aiuta a comprendere la logica di business.

  • La descrizione è una stringa tradotta nella lingua dell'utente corrente (probabilmente CultureInfo.CurrentCulture ).

risposta data 05.07.2014 - 01:05
fonte
2

Se ritieni di non poter aggiungere alcuna informazione utile al futuro lettore di questa classe nei commenti, non scriverlo. A mio parere il tuo codice non ha bisogno di commenti, è piuttosto ovvio, i commenti in questo codice sono più rumore di informazioni reali.

Un linguaggio di programmazione è ovviamente una lingua, quando si inserisce un commento è perché non è possibile esprimere le cose che si desidera esprimere in questo linguaggio di programmazione e si utilizza un altro linguaggio che offre maggiore libertà e strumenti per esprimere (a linguaggio umano come l'inglese). A volte puoi giustificare questo perché il linguaggio di programmazione può avere alcune caratteristiche o modi oscuri per fare cose che necessitano di una spiegazione, o forse usi qualche libreria di terze parti con un comportamento molto strano piuttosto che un'esplosione. Ma IMMO la maggior parte del codice non ha bisogno dell'uso di un linguaggio umano per esprimere le cose, molte volte i commenti riflettono un cattivo design, cattiva scelta del nome, cattiva architettura ecc, ecc.

Ogni volta che penso "ho bisogno di un commento qui per gli altri per capirlo", è stato messo in allerta e cerco di ripensare il mio progetto, cercare nomi migliori, fare alcuni refactatori, ecc., a volte questo mi aiuta a trovare una soluzione migliore e non ho bisogno del commento, a volte non trovo una soluzione migliore e ho inserito il commento, ma non ho mai inserito un commento prima di tentare di esprimere le cose in modo più chiaro nel mio linguaggio di programmazione. / p>     

risposta data 05.07.2014 - 03:51
fonte
0

Scrivo commenti per due scopi

  1. Commenti XML classe / metodo. Fornire un contesto per ciò che fa un metodo / classe / frammento e perché potrebbe esserci. Questo può "ripetere" ciò che esprime chiaramente il codice, ma solo la persona che lo ha scritto. Se il commento può dirmi cosa sta succedendo senza comprendere il codice, è un vantaggio
  2. Per evidenziare i casi limite. Nel caso in cui dovessi gestire un caso specifico, lascerò un commento in linea.

Per espandere il mio commento:

Se cercassi dei commenti, noterei che non so cosa restituisca GetUserById se non viene trovato un utente con un determinato ID (Null, default o genera un'eccezione).

In parole povere vorrei lasciare un commento sullo stato di creazione dicendo che viene restituito uno stato di conflitto quando l'id dell'entità corrisponde a un id utente esistente.

I commenti possono sembrare che stiano rigurgitando il codice, ma questo è solo per coloro che lo leggono e lo capiscono. Considera che non è necessario farlo per poterlo utilizzare.

    
risposta data 05.07.2014 - 06:09
fonte

Leggi altre domande sui tag