-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enforce LeftCurly rule #6452
Enforce LeftCurly rule #6452
Conversation
Argh, again some temporary issues: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does intellij and eclipse support automatic formatting according to this rule? Stricter code formatting rules are fine with me as long as I don't have to manually fix the formatting.
Moreover, some of the changes to the javadoc comments seem strange to me.
* A value of 1 means that the editor gets exactly as much space as all other regular editors. | ||
* A value of 2 means that the editor gets twice as much space as regular editors. | ||
* <p> | ||
* A value of 1 means that the editor gets exactly as much space as all other regular editors. A value of 2 means |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor point: Did you do this manually or via your code editor? The previous version was better in my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -99,7 +99,8 @@ public MainTableColumnModel(Type type, String qualifier) { | |||
} | |||
|
|||
/** | |||
* This is used by the preferences dialog, to initialize available basic icon columns, the user can add to the table. | |||
* This is used by the preferences dialog, to initialize available basic icon columns, the user can add to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, why the added line break?
* XML-Syntax-Highlighting for RichTextFX-Codearea created by (c) Carlos Martins (github: @cemartins) | ||
* License: BSD-2-Clause | ||
* see https://github.com/FXMisc/RichTextFX/blob/master/LICENSE and: | ||
* XML-Syntax-Highlighting for RichTextFX-Codearea created by (c) Carlos Martins (github: @cemartins) License: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...
I pressed automatic reformat in IntelliJ. No manual changes. If we do not want to have these changes, we need to modify our automatic formatting rules. |
This is a step forward that we are back in 2015, where we enforced that all contributors pressed Ctrl+Alt+L (in IntelliJ) to ensure proper formatting of the whole file. |
config/IntelliJ Code Style.xml
Outdated
<option name="WRAP_COMMENTS" value="true" /> | ||
<code_scheme name="JabRef" version="173"> | ||
<option name="RIGHT_MARGIN" value="140" /> | ||
<option name="WRAP_WHEN_TYPING_REACHES_RIGHT_MARGIN" value="true" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we had a discussion about this some time ago and decided against having a hard line wrap (reasoning was "old school, everybody has wide monitors now anyway" if I remember correctly).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, no hard-line wrap. I remember the discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, we did not adapt the config and we had no issues until I applied the automatic formatting today. Either none of use applied to automatic formatting before or was a wizzard in git gui
only committing the reformat of code; not that of the comments.
I did the latter one often. However, currentyl, I believe, I cannot really explain to contributors that we have automatic tooling, but one cannot fully use it.
I changed the limit to 500 characters at 59938a9. This should be high enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the hard limit as we have files with 510 or 5000 characters line length.
I changed the maximum columsn from
Discussions in the net
|
Filed an issue to IntelliJ, because it automatically reformats the JavaDoc even if not told so |
- Array initializers have to be separated by space - Space in single-line enums
Reformatted all files according to our IntelliJ formatting settings. I did not commit the change to one single line in the JavaDoc, but used the other changes. Now all students can format the their contribution automatically. For Eclipse, we need to check. Since these will be minor issues, I would propose to handle that as soon as an issue arises. |
# Conflicts: # src/main/java/org/jabref/gui/DialogService.java # src/main/java/org/jabref/gui/StateManager.java
* upstream/master: (50 commits) Keep group pane size when resizing window (#6180) (#6423) Changelog: Fix missing citation for biblatex-mla Update AUTHORS Check duplicate DOI (#6333) Fix missing citation for biblatex-mla Change EasyBind dependency (#6480) Add testing of latest dev version as mandatory Squashed 'src/main/resources/csl-styles/' changes from 5dad23d..586e0b8 Fix libre office connection and other progress dialogs (#6478) Fix clear year and month field when converting to biblatex (#6434) Add truncate as a BibTex key modifier (#6427) Add new authors (not all - they need more work) Remove empty line Add simple Unit Tests for #6207 (#6240) Enforce LeftCurly rule (#6452) Implement task progress indicator (and dialog) in the toolbar (#6443) Consider empty brackets Changelog update Added a test Fixed brackets in regular expressions ...
This is a follow-up to #6283.
I open this PR just for documentation. No need to review.
While reviewing #6426, I found out, the contributors did not have setup the code style properly. Thus, I now put LeftCurly in place, which enforces that there are no statements directly appended after an if.
I am aware that for simple values, this causes more lines without improving things. Nevertheless, I vote for consistent code.
The future should be to rewrite minor code style issues (unused imports, line breaks, ...) automatically. The current tool of choise is spotless. Also Google's refaster should be put in place. It has very advanced rewriting templates. For instance:
can be automatically rewritten to
assertTrue(...);