Sovrapposizione di commenti descrittivi nelle dichiarazioni di classe

Question

Sovrapposizione di commenti descrittivi nelle dichiarazioni di classe

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Quando dichiaro nuove classi mi piace strutturarle in uno stile specifico. Ogni public , protected e private parola chiave viene utilizzata per dichiarare metodi o attributi, mai entrambi. Per chiarire ulteriormente le parti, utilizzo brevi commenti descrittivi come nell'esempio seguente:

class SomeRandomName 
{
  public: /* methods */
    // some public methods
  private: /* methods */
    // some private methods
  private: /* attributes */
    // some private attributes
}

Se una classe avesse anche metodi e attributi protetti, questo potrebbe essere piuttosto lungo e mi stavo chiedendo

I commenti extra "descrittivi" sono necessari o rendono il codice effettivamente più difficile da leggere?
ed è una buona idea separare metodi e attributi nelle proprie sezioni comunque?

coding-style c++

posta muXXmit2X 08.03.2017 - 08:02

fonte

3 risposte

1

Oltre al significato del testo, è l'immagine del codice a cui ti sei abituato che ti dà la consapevolezza di ciò che stai guardando, di dove sei. Qualunque cosa sia formattata in modo diverso da quello a cui sei abituato sembrerà sconcertante e sarà più difficile per te. Se sei in una squadra, dovresti alla fine sviluppare lo stesso senso di ciò che sembra "giusto".

Quindi, anche se hai poco da dire in un commento, può essere sensato aggiungerlo, solo per dare al tuo codice l'aspetto coerente con cui ti trovi a tuo agio. Qualcuno che non trova conforto nel modo in cui si formatta il codice potrebbe tuttavia trovare "solo più rumore". Quindi, sii consapevole del tuo ambiente.

risposta data 08.03.2017 - 08:28

fonte

0

Se hai Java a cercare l'origine di Interface List, hai solo un metodo vuoto poiché è un'interfaccia e hai 10 righe di commenti per metodo. Anche in ArrayList hai più commenti sul codice.

Quindi non avere commenti ovunque non è necessario fare un overdoing. Comunque assicurati che il tuo commento sia utile, commenta come "Questo è il prezzo dell'articolo" su un prezzo di una classe Articolo non portare nulla.

Ricorda che i commenti sono documentazione tecnica, scrivi una frase breve, direttamente al punto.

Vedi questo SO post per l'ordine di dichiarazione.

risposta data 08.03.2017 - 08:26

fonte

Leggi altre domande sui tag coding-style c++

È una cattiva progettazione condividere una classe tra un agente in un sistema e un sito Web di frontend Relazione database da N t ... 1 a N .. N

score 2 · Accepted Answer

Oggettivamente, queste sezioni separate rendono il codice più difficile da leggere, perché più parti richiedono più capacità intellettuali da elaborare.

I commenti non sono realmente necessari e lo rendono meno facile da leggere (perché i commenti sono aspetti importanti che non dovrebbero essere trascurati). Invece, dovresti tenere un piccolo file di "stile di codifica" in cui spieghi una volta per tutte queste convenzioni.

Penso che sia una buona pratica raggruppare il più possibile le variabili su un lato e le funzioni sull'altro (e tipi in un terzo).

Ma non cercare di farlo aggiungendo barriere artificiali aggiuntive. Questi solo rendono più difficile la lettura e danno un falso senso di sicurezza: come il compilatore non controlla, non hai assicurazione che non ci sia una mancata corrispondenza da qualche parte.