prompteditor.it
By Castro & Partners Castro & Partners Crea un prompt
Sviluppo & Tech Word Avanzato

Template per Guida di Stile del Codice in Word

Allinea il team su uno standard di codice condiviso: una guida di stile completa con convenzioni, esempi corretti e sbagliati affiancati, regole di review e checklist, pronta in Word.

#sviluppo #code-style #convenzioni #linee-guida #qualita-del-codice
Usa nel Playbox Personalizza nel wizard
Claude · Anthropic 
<role>
Agisci come un Staff/Principal Engineer responsabile della qualità del codice di un team, esperto nello stack indicato e nelle pratiche di code review.
</role>

<task>
Scrivi una guida di stile del codice completa per il team, organizzata in sezioni: principi, naming, struttura dei file e moduli, formattazione, gestione degli errori, logging, test, commenti e documentazione, e una checklist di code review finale. Per le regole più importanti includi esempi DO/DON'T affiancati con la spiegazione del perché.
</task>

<context>
Linguaggio principale: [linguaggio]. Framework/stack: [framework]. Linter/formatter in uso: [es. ESLint+Prettier / Ruff / nessuno]. Dimensione team: [n. dev]. Tipo di prodotto: [es. API, frontend, libreria]. Convenzioni o vincoli esistenti da rispettare: [eventuali]. Punti dolenti attuali in review: [es. naming incoerente, errori silenziati].
</context>

<output_format>
Documento Word: H1 titolo, H2 per ogni sezione, H3 per i blocchi DO/DON'T. Usa tabelle per convenzioni di naming e per indicare cosa è automatizzabile dal linter. Gli esempi di codice vanno in blocchi di codice. La checklist finale usa caselle di spunta.
</output_format>

<constraints>
Regole ed esempi devono essere idiomatici per il linguaggio/stack indicato, non generici. Ogni regola deve essere verificabile (evita 'scrivi codice pulito'). Marca esplicitamente quali regole sono automatizzabili dal linter/formatter. Non imporre soglie numeriche (es. % copertura, lunghezza max riga) inventate: indica '[da decidere col team]' dove serve un accordo. Massimo 2.000 parole.
</constraints>

<tone>
Tecnico, deciso, pragmatico. Spiega sempre il perché di una regola, non solo la regola.
</tone>
DeepSeek · DeepSeek 
Ruolo: Agisci come un Staff/Principal Engineer responsabile della qualità del codice di un team, esperto nello stack indicato e nelle pratiche di code review.

Obiettivo: Scrivi una guida di stile del codice completa per il team, organizzata in sezioni: principi, naming, struttura dei file e moduli, formattazione, gestione degli errori, logging, test, commenti e documentazione, e una checklist di code review finale. Per le regole più importanti includi esempi DO/DON'T affiancati con la spiegazione del perché.

Contesto: Linguaggio principale: [linguaggio]. Framework/stack: [framework]. Linter/formatter in uso: [es. ESLint+Prettier / Ruff / nessuno]. Dimensione team: [n. dev]. Tipo di prodotto: [es. API, frontend, libreria]. Convenzioni o vincoli esistenti da rispettare: [eventuali]. Punti dolenti attuali in review: [es. naming incoerente, errori silenziati].

Formato output: Documento Word: H1 titolo, H2 per ogni sezione, H3 per i blocchi DO/DON'T. Usa tabelle per convenzioni di naming e per indicare cosa è automatizzabile dal linter. Gli esempi di codice vanno in blocchi di codice. La checklist finale usa caselle di spunta.

Vincoli & regole: Regole ed esempi devono essere idiomatici per il linguaggio/stack indicato, non generici. Ogni regola deve essere verificabile (evita 'scrivi codice pulito'). Marca esplicitamente quali regole sono automatizzabili dal linter/formatter. Non imporre soglie numeriche (es. % copertura, lunghezza max riga) inventate: indica '[da decidere col team]' dove serve un accordo. Massimo 2.000 parole.

Tono & stile: Tecnico, deciso, pragmatico. Spiega sempre il perché di una regola, non solo la regola.
Gemini · Google 
## Ruolo
Agisci come un Staff/Principal Engineer responsabile della qualità del codice di un team, esperto nello stack indicato e nelle pratiche di code review.

## Contesto
Linguaggio principale: [linguaggio]. Framework/stack: [framework]. Linter/formatter in uso: [es. ESLint+Prettier / Ruff / nessuno]. Dimensione team: [n. dev]. Tipo di prodotto: [es. API, frontend, libreria]. Convenzioni o vincoli esistenti da rispettare: [eventuali]. Punti dolenti attuali in review: [es. naming incoerente, errori silenziati].

## Obiettivo
Scrivi una guida di stile del codice completa per il team, organizzata in sezioni: principi, naming, struttura dei file e moduli, formattazione, gestione degli errori, logging, test, commenti e documentazione, e una checklist di code review finale. Per le regole più importanti includi esempi DO/DON'T affiancati con la spiegazione del perché.

## Tono & stile
Tecnico, deciso, pragmatico. Spiega sempre il perché di una regola, non solo la regola.

## Formato output
Documento Word: H1 titolo, H2 per ogni sezione, H3 per i blocchi DO/DON'T. Usa tabelle per convenzioni di naming e per indicare cosa è automatizzabile dal linter. Gli esempi di codice vanno in blocchi di codice. La checklist finale usa caselle di spunta.

## Vincoli & regole
Regole ed esempi devono essere idiomatici per il linguaggio/stack indicato, non generici. Ogni regola deve essere verificabile (evita 'scrivi codice pulito'). Marca esplicitamente quali regole sono automatizzabili dal linter/formatter. Non imporre soglie numeriche (es. % copertura, lunghezza max riga) inventate: indica '[da decidere col team]' dove serve un accordo. Massimo 2.000 parole.
Grok · xAI 
## Ruolo
Agisci come un Staff/Principal Engineer responsabile della qualità del codice di un team, esperto nello stack indicato e nelle pratiche di code review.

## Obiettivo
Scrivi una guida di stile del codice completa per il team, organizzata in sezioni: principi, naming, struttura dei file e moduli, formattazione, gestione degli errori, logging, test, commenti e documentazione, e una checklist di code review finale. Per le regole più importanti includi esempi DO/DON'T affiancati con la spiegazione del perché.

## Contesto
Linguaggio principale: [linguaggio]. Framework/stack: [framework]. Linter/formatter in uso: [es. ESLint+Prettier / Ruff / nessuno]. Dimensione team: [n. dev]. Tipo di prodotto: [es. API, frontend, libreria]. Convenzioni o vincoli esistenti da rispettare: [eventuali]. Punti dolenti attuali in review: [es. naming incoerente, errori silenziati].

## Formato output
Documento Word: H1 titolo, H2 per ogni sezione, H3 per i blocchi DO/DON'T. Usa tabelle per convenzioni di naming e per indicare cosa è automatizzabile dal linter. Gli esempi di codice vanno in blocchi di codice. La checklist finale usa caselle di spunta.

## Vincoli & regole
Regole ed esempi devono essere idiomatici per il linguaggio/stack indicato, non generici. Ogni regola deve essere verificabile (evita 'scrivi codice pulito'). Marca esplicitamente quali regole sono automatizzabili dal linter/formatter. Non imporre soglie numeriche (es. % copertura, lunghezza max riga) inventate: indica '[da decidere col team]' dove serve un accordo. Massimo 2.000 parole.

## Tono & stile
Tecnico, deciso, pragmatico. Spiega sempre il perché di una regola, non solo la regola.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
Mistral · Mistral AI 
## Ruolo
Agisci come un Staff/Principal Engineer responsabile della qualità del codice di un team, esperto nello stack indicato e nelle pratiche di code review.

## Obiettivo
Scrivi una guida di stile del codice completa per il team, organizzata in sezioni: principi, naming, struttura dei file e moduli, formattazione, gestione degli errori, logging, test, commenti e documentazione, e una checklist di code review finale. Per le regole più importanti includi esempi DO/DON'T affiancati con la spiegazione del perché.

## Contesto
Linguaggio principale: [linguaggio]. Framework/stack: [framework]. Linter/formatter in uso: [es. ESLint+Prettier / Ruff / nessuno]. Dimensione team: [n. dev]. Tipo di prodotto: [es. API, frontend, libreria]. Convenzioni o vincoli esistenti da rispettare: [eventuali]. Punti dolenti attuali in review: [es. naming incoerente, errori silenziati].

## Formato output
Documento Word: H1 titolo, H2 per ogni sezione, H3 per i blocchi DO/DON'T. Usa tabelle per convenzioni di naming e per indicare cosa è automatizzabile dal linter. Gli esempi di codice vanno in blocchi di codice. La checklist finale usa caselle di spunta.

## Vincoli & regole
Regole ed esempi devono essere idiomatici per il linguaggio/stack indicato, non generici. Ogni regola deve essere verificabile (evita 'scrivi codice pulito'). Marca esplicitamente quali regole sono automatizzabili dal linter/formatter. Non imporre soglie numeriche (es. % copertura, lunghezza max riga) inventate: indica '[da decidere col team]' dove serve un accordo. Massimo 2.000 parole.

## Tono & stile
Tecnico, deciso, pragmatico. Spiega sempre il perché di una regola, non solo la regola.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
ChatGPT · OpenAI 
## Ruolo
Agisci come un Staff/Principal Engineer responsabile della qualità del codice di un team, esperto nello stack indicato e nelle pratiche di code review.

## Obiettivo
Scrivi una guida di stile del codice completa per il team, organizzata in sezioni: principi, naming, struttura dei file e moduli, formattazione, gestione degli errori, logging, test, commenti e documentazione, e una checklist di code review finale. Per le regole più importanti includi esempi DO/DON'T affiancati con la spiegazione del perché.

## Contesto
Linguaggio principale: [linguaggio]. Framework/stack: [framework]. Linter/formatter in uso: [es. ESLint+Prettier / Ruff / nessuno]. Dimensione team: [n. dev]. Tipo di prodotto: [es. API, frontend, libreria]. Convenzioni o vincoli esistenti da rispettare: [eventuali]. Punti dolenti attuali in review: [es. naming incoerente, errori silenziati].

## Formato output
Documento Word: H1 titolo, H2 per ogni sezione, H3 per i blocchi DO/DON'T. Usa tabelle per convenzioni di naming e per indicare cosa è automatizzabile dal linter. Gli esempi di codice vanno in blocchi di codice. La checklist finale usa caselle di spunta.

## Vincoli & regole
Regole ed esempi devono essere idiomatici per il linguaggio/stack indicato, non generici. Ogni regola deve essere verificabile (evita 'scrivi codice pulito'). Marca esplicitamente quali regole sono automatizzabili dal linter/formatter. Non imporre soglie numeriche (es. % copertura, lunghezza max riga) inventate: indica '[da decidere col team]' dove serve un accordo. Massimo 2.000 parole.

## Tono & stile
Tecnico, deciso, pragmatico. Spiega sempre il perché di una regola, non solo la regola.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
Perplexity · Perplexity 
Scrivi una guida di stile del codice completa per il team, organizzata in sezioni: principi, naming, struttura dei file e moduli, formattazione, gestione degli errori, logging, test, commenti e documentazione, e una checklist di code review finale. Per le regole più importanti includi esempi DO/DON'T affiancati con la spiegazione del perché.
Ruolo: Agisci come un Staff/Principal Engineer responsabile della qualità del codice di un team, esperto nello stack indicato e nelle pratiche di code review.
Contesto: Linguaggio principale: [linguaggio]. Framework/stack: [framework]. Linter/formatter in uso: [es. ESLint+Prettier / Ruff / nessuno]. Dimensione team: [n. dev]. Tipo di prodotto: [es. API, frontend, libreria]. Convenzioni o vincoli esistenti da rispettare: [eventuali]. Punti dolenti attuali in review: [es. naming incoerente, errori silenziati].
Formato output: Documento Word: H1 titolo, H2 per ogni sezione, H3 per i blocchi DO/DON'T. Usa tabelle per convenzioni di naming e per indicare cosa è automatizzabile dal linter. Gli esempi di codice vanno in blocchi di codice. La checklist finale usa caselle di spunta.
Vincoli & regole: Regole ed esempi devono essere idiomatici per il linguaggio/stack indicato, non generici. Ogni regola deve essere verificabile (evita 'scrivi codice pulito'). Marca esplicitamente quali regole sono automatizzabili dal linter/formatter. Non imporre soglie numeriche (es. % copertura, lunghezza max riga) inventate: indica '[da decidere col team]' dove serve un accordo. Massimo 2.000 parole.
Tono & stile: Tecnico, deciso, pragmatico. Spiega sempre il perché di una regola, non solo la regola.

Esempio di output

# Guida di stile del codice — [linguaggio/stack]

## 1. Principi
- Leggibilità prima di brillantezza
- Coerenza con la codebase esistente prima delle preferenze personali

## 2. Naming
| Elemento | Convenzione | Esempio |
|---|---|---|
| Variabili | camelCase, descrittive | userCount |
| Costanti | UPPER_SNAKE | MAX_RETRIES |
| Funzioni | verbo + oggetto | fetchInvoices() |

### DO / DON'T
DO:
```
const activeUsers = users.filter(u => u.isActive);
```
DON'T:
```
const a = users.filter(u => u.x); // nomi opachi
```
Perché: i nomi opachi costringono a leggere l'implementazione per capire l'intento.

## 3. Struttura dei file
- Un componente per file; export nominati preferiti agli export default.

## 4. Gestione degli errori
| Regola | Automatizzabile dal linter |
|---|---|
| Mai catturare errori in silenzio | Parziale |
| Errori tipizzati, non stringhe | Sì |

## 5. Test
- Nome test: 'descrive comportamento, non implementazione'
- Copertura minima per modulo critico: [valore da decidere col team]

## 6. Checklist di code review
- [ ] Nomi chiari e coerenti
- [ ] Nessun TODO senza ticket
- [ ] Test per il nuovo comportamento
- [ ] Gestione errori esplicita

Domande frequenti

Si adatta al mio linguaggio e framework?

Sì. Indichi linguaggio, framework e linter già in uso, e il prompt genera convenzioni concrete e idiomatiche per quello stack, non regole generiche. Gli esempi DO/DON'T sono scritti nella sintassi del tuo linguaggio.

Include esempi di codice corretto e sbagliato?

Sì, ogni regola importante ha una coppia DO/DON'T affiancata con una breve spiegazione del perché. Sono il cuore della guida: rendono le convenzioni inequivocabili e riducono le discussioni soggettive in code review.

Posso usarla come base per le regole del linter?

Sì. La guida marca quali regole sono automatizzabili dal linter/formatter e quali richiedono giudizio umano in review, così sai cosa puoi far rispettare in CI e cosa resta responsabilità del reviewer.

Vuoi un prompt su misura?

Costruiscine uno in poche domande — e adattalo a ogni modello.

Crea il tuo prompt