LMMS / LMMS/lmms

Code style should be enforced by tooling.

Open
#3,856 4 comments 1 reaction 0 assignees View on GitHub
enhancement
Dominant language
C++
Stars
10.4k
Forks
1.3k
Avg merge
2d 13h
Merged PRs (30d)
7

Description

Currently the code style for LMMS is enforced only through code review. This leads to inconsistencies as reviewers miss style violations and delays when developers find out about these violations. It would be convenient to have a tool such as clang-format enforce a style so that developers didn't have to worry about it.

The current coding style is described at https://github.com/LMMS/lmms/wiki/Coding-conventions. This style fails to define some things:

The standard does not define if pointers and references should be attached to the type, attached to the variable, or attached to neither. Currently attached to neither and attached to type are both very commn.
```int* attachedToType```
```int * attachedToNeither```
```int *attachedToVariable```

The standard does not define when there should be a newline before a ```{```. The most common answer to this seems to be "always' but there are a significant number of places where this is not followed.

The standard does not state that there should not be spaces within '''()'''

There may be other places where the standard is silent but shouldn't be.

I propose that a '''.clang-format''' file be added to enforce a code style for the application and that a CI check be added to ensure that the code is formatted correctly. To do this decisions must be made about the things that the standard is silent on.

The addition of a clang-format file and subsequent reformatting of the code would ideally happen shortly after the 1.2.0 branch is merged back to master. This would allow for the smallest possible amount of merge conflicts.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the LMMS Coding conventions wiki page and inspect the repository's existing C++ formatting. The work is done when the unresolved style choices are decided, a .clang-format file and CI formatting check are added, and the code is consistently reformatted after the 1.2.0 merge.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
ci-cd, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.