You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should really think about adopting an .editorconfig file for the project. Placed in the top-level directory, it will "encourage" developers' code editors to format things the preferred way. (Though it may require installing/activating a plugin, for some software.)
An .editorconfig could easily curb @jonoomph 's habit of checking in source files without a trailing newline, as well. 😉
Using an .editorconfig is generally less drastic and invasive than defining git hooks to reformat source files, since it doesn't force file-wide reformatting when checking in a change that only touches a single line, and exceptions can be defined at individual-file granularity for any existing files that don't quite conform to the preferred formatting, but which we don't want to completely reformat for now.
(File-wide reformatting is a drastic step, and can cause unwanted side effects. Because it steamrolls over the git blame history for the source lines, it means that the person who checks in the reformatted code shows up as the author of every line in the file. That can be problematic when attempting to trace individual lines of code back to their maintainer/author, since it's often desirable to get that person's input on any subsequent changes to that code.)
The text was updated successfully, but these errors were encountered:
It's harmless change. But it is good to know format rules that is preferable for c++, python, .ui and other files of the project (including openshot-qt files). Key points: indentation, parenthesis, functions and variable naming, comments, max string length and wrapping. Is the web version of the git editor doing good for you, for example?
Is the web version of the git editor doing good for you, for example?
I almost never use it for code editing, TBH. If I do it's generally only for quick fixes to documentation or config files.
Lately I've been working mostly in GitHub's Atom, which has a plugin to enable a fairly limited set of editorconfig features. It serves for basic style hints, though nothing like some IDEs support. (I can't find the list now, but IntelliJ IDEA's editorconfig extensions are pretty insane.)
Supported properties:
root
charset
end_of_line
indent_style
indent_size / tab_width (indent_size takes precedence over tab_width)
insert_final_newline (setting this to false strips final newlines)
max_line_length
trim_trailing_whitespace
It does have the nice feature that:
⚠️ EditorConfig will not automatically fix malformed files (e.g. change all soft tabs to hard tabs) -- you need to use the EditorConfig: Fix File command on each malformed file. Keep in mind that malformed files (especially mixed tab characters) may lead to unexpected behaviour.
So, like I mentioned above, none of that git hook "change one line, the whole file gets reformatted on commit" stuff. Unless I explicitly request it.
We should really think about adopting an
.editorconfig
file for the project. Placed in the top-level directory, it will "encourage" developers' code editors to format things the preferred way. (Though it may require installing/activating a plugin, for some software.)An
.editorconfig
could easily curb @jonoomph 's habit of checking in source files without a trailing newline, as well. 😉Using an
.editorconfig
is generally less drastic and invasive than defining git hooks to reformat source files, since it doesn't force file-wide reformatting when checking in a change that only touches a single line, and exceptions can be defined at individual-file granularity for any existing files that don't quite conform to the preferred formatting, but which we don't want to completely reformat for now.(File-wide reformatting is a drastic step, and can cause unwanted side effects. Because it steamrolls over the
git blame
history for the source lines, it means that the person who checks in the reformatted code shows up as the author of every line in the file. That can be problematic when attempting to trace individual lines of code back to their maintainer/author, since it's often desirable to get that person's input on any subsequent changes to that code.)The text was updated successfully, but these errors were encountered: