Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Decide on and enforce house C++ style

Aperta
  • Qualcosa non va?
#994 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
cpp
Ambito
tooling

Direzione di ricerca

Iniziate esaminando gli esempi di denominazione proposti in questa issue e la pull request correlata #992. Utilizzate il controllo readability-identifier-naming di clang-tidy per valutare come potrebbero essere applicate le convenzioni proposte. Il lavoro è completato solo dopo che il progetto ha concordato uno stile e definito un approccio alla migrazione; non sono stati identificati file o test specifici.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Introduction

After https://github.com/runtimeverification/llvm-backend/pull/992 [^1], I think it's worth putting the effort in to properly clean up our C++ code with a house style. We use a bunch of different styles in the C++ code, and there is no strong consensus for what the correct solution will look like. This issue is an attempt at an opinionated set of defaults that we can bikeshed, then start to apply gradually to the code.[^2]

[!NOTE]
There are a few things that are out of scope here. We already have a consistent structural style for the code that's enforced conveniently by clang-format, and similarly we have a lot of semantic best practices and conventions being enforced by clang-tidy. We can therefore restrict the bikeshedding here to naming aesthetics and consistency.

Proposed Style


#define MACRO_IF_NEEDED(x) x

namespace some_namespace_name {

enum class some_enum {
  variant_a,
  variant_b,
};

template <typename TypeParameter>
class some_class_name {
public:
  void member_function() const;

private:
  int member_variable_ = 0;
};

void some_class_name::member_function() const {
  auto local_var = f();
  free_function(member_variable_);
}

void free_function(int my_parameter_name) {
  ...
}

}

Some things we should also consider that are not directly naming style:

  • Prefixing extern "C" functions with a prefix like kllvm_ (see #992)
  • Using namespaces rather than purely textual namespacing (e.g. kore::composite_pattern rather than kllvm::KORECompositePattern).

Migration Strategy

Once we agree on a style, it should be easily achievable to migrate one stylistic element at a time using clang-tidy.

[^1]: We'd have avoided this pain by enforcing a consistent naming prefix for our C code so as to remain hygienic when interfacing with the outside world. Nobody other than us is naming their functions kllvm_arena_alloc!
[^2]: We can hopefully clean up or improve some of the bigger, gnarlier functions that are currently exempted from clang-tidy's congitive-complexity warnings when we do this.

Lingua principale
C++
Stelle
43
Fork
22
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di runtimeverification/llvm-backend

Tutte le issue di runtimeverification/llvm-backend

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.