Hy all,
In IntelliJ I have set the "Hard wrap at" limit to 100 lines and want all lines that are longer then that to be wrapped by IntelliJ (including Indentation of course) when I reformat the file.
This works for everything except long method names in one of my interfaces (Note: Purple underline is checkstyle which also says its too long):
This alone would not be a huge issue, I can just make a line break myself.
The main issue is, that a manual line break puts the method name on the same indentation level as the method description (which again checkstyle correctly does not like) and when I indent it manually, a reformat of the file moves the line back to this level. So IntelliJs reformat file moves it to the wrong location.
Does somebody have any idea, which setting this is and what I have to change to at least have the correct indentation and at best also the corret wrapping?
Greets
Chris
Related
I'm currently working on an application in Eclipse where I'm running a really huge SQL statement that spans about 20 lines when splitting it in notepad to fit on the screen. Thus I want the string for the query also to be formatted somewhat more readable than a single line. All the time autoformatting normally worked when I used Eclipse but somehow now neither Ctrl + Alt + F nor rightclicking and selecting the "Format" option from the menu doesn't work to get a line break after a certain amount of characters.
I already checked the preferences where I already tried running my own profile with 120 and 100 characters line width but that didn't fix anything so far. I really don't know why Eclipse won't let me format this anymore. Normally Eclipse would be splitting the string into several lines in this case but I don't really know why this doesn't work anymore.
However other formatting is being fixed when executing autoformatting (e.g. if(xyz){ still becomes if (xyz) {.
Thank you for your help in advance.
As far as I can tell, autoformat as you described was never supported (at least as far back as 2008). And I have been using Eclipse much longer than that
You can do one of several things.
Simply insert the cursor in the string and hit a return.
Toggle word wrap Alt-Shift-Y
Try writing a regex to do what you want(not certain if this will work).
A colleague's Eclipse formatting rules cause extreme indentation, and wraps comments to look like this:
// this
// is
// indented
// several
// tabs
They're wrapped at every word boundary because they're indented all the way past the line wrap width. I can reformat them to look only slightly more sane:
// this
// is
// indented
// several
// tabs
but the wrapping remains. Is there any way I can automagically undo this wrapping so that I won't have to spend 30 minutes every time I commit to manually reformat these comments and make the comments readable again? I don't care if other line breaks are not preserved; that would be a reasonable trade. Target result:
// this is indented several tabs
You are not the first to be frustrated by this (me included) I have never found an answer on how to undo this kind of formatting in a great way.
To prevent it happening again, there is of course the option of fixing the formatting rules and then applying them to the project instead of to the workspace. That ensures that if your colleague does format it won't be ruined like this. I recommend setting (in Comments tab of formatter):
turn on Never indent line comments on first column --> this prevents commented out code from being indented and lost
turn off Enable line comment formatting --> this fixes the wrapping problem
Take those settings, followed by using block /* */ comments for actual block comments (instead of what I often see of using line // comments for block comments).
Some other SO users who have posted similar questions with no full resolution, but some suggestions that may help. Such as using a third party formatter (perhaps only once to recover your code state and then continuing as above?)
How to reformat multi-line comments in Eclipse PDT?
Join Lines in Eclipse
I don't think this will be possible with standard IDEs; whilst they're usually good at reflowing lines over the margin, most are reticent to reflow legitimate lines (for good reasons, generally).
That said, I know you do this semi-automatically in IntelliJ IDEA at (sorry haven't used Eclipse for a while but I think it's now possible):
Select the lines with comments and type Ctrl-Shift-J (or equivalent mapping to join lines). This immediately pulls them into one line. Ctrl-Alt-L to reformat that selection if you need to.
It's that or regex I guess.. but be warned...
Try going to Windows -> Preferences -> Java -> Code Style -> Formatter and then click the Edit... button towards the top right under the Active Profile header.
Mess around with the settings in there, specifically the Line Wrapping and Comments tab.
Often times my code does not fit on the same line, I want to place them on the next line to increase readability, but everytime eclipse always create incorrect indent. Is there a way I can ask eclipse to indent properly?
I tried the solution on this question, but it does not seems to do anything for me.
Although you can specify properties such as this in the preferences of the IDE, your indentation preferences are not recommended. The eclipse identations are proper.
Single identations, as you would like, are used to denote the opening of blocks of code such as the following (Curly braces):
if (i = 1) {
//Single identation here
}
Double identation is used for situations such as the following (parenthesis):
System.out.println("This is some string that"
+ " I want to continue on the next line");
In conclusion, you can change it, but Eclipse is actually doing it right to avoid confusion between the two.
In my current project, we always insert an empty new line at the end of the Java source files. We also enforce this with CheckStyle (with error level).
I was searching for this topic for a long time, but unfortunately I can't find any convincing reason for this. It seems that other developers are pretty indifferent about this because they just checked one checkbox in Eclipse formatter and it's done automatically. But I still don't know why it is needed and why it can be important. So my question is:
Why are empty lines at the end of Java source files needed?
Is it a current need or a relic of the past and undesirable in current code bases?
I think they are trying to ensure every file ends with a trailing newline character. This is different from ending with a blank line, a.k.a. empty newline.
Edit: As #Easy Angel succinctly clarified in the comments: trailing newline = "\n" and blank line = "\n\n"
I think either:
your lead is either mandating that every file ends with a newline character, but its being misinterpreted as mandating that every file end with a blank line (i.e. an empty line that ends in a newline), or else
they are trying to ensure every file ends with a newline character by actually mandating every file end with a blank line (a.k.a. empty line that ends with a newline), thereby ensuring files ends with at least one newline (and possibly redundant additional newline - overkill?).
Unless the editor actually shows newline symbols, its not always clear in some editors that a file:
DOES NOT END a newline at all,
ENDS with a single trailing newline, or
ENDS with a blank newline, i.e. 2 trailing newlines
I think most modern source code editors insert a trailing newline. However, when using older more general editors, I would always try to ensure my source code files (and text files in general) always ended with a trailing newline (which occasionally came out as a blank line/empty newline depending on the editor I was using) because:
when using cat to display the file on the command line, if the file lacked a trailing newline, the next output (like the shell prompt or a visual delimiter a script may output between files) would end up appearing right after the last non-newline character rather than starting on a newline. In general, the trailing newline made files more user- and script- friendly.
I believe some editors (I can't remember any specifics) would automatically insert a trailing newline if the text file lacked one. This would make it appear like the file was modified. It would get confusing if you have a bunch of files open in different windows and then go to close all of them - the editor prompts you to save but you are unsure whether you made "real changes" to the file or its just the auto-inserted newline.
Some tools like diff and some compilers will complain about a missing trailing newline. This is more noise that users and tools may have to deal with.
Edit:
About editors adding newlines and not being able to see whether there's a newline vs blank newline at the end of the file, I just tested Vim, Eclipse, and Emacs (on my Windows system with Cygwin): I opened a new file, typed 'h' 'e' 'l' 'l' 'o' and saved without hitting [ENTER]. I examined each file with od -c -t x1.
Vim did add a trailing newline.
Emacs did add a trailing newline.
Eclipse did NOT add a trailing newline.
But
Vim did NOT allow me to cursor down to a blank line under "hello".
Emacs did allow me to cursor down to a blank line under "hello".
Eclipse did NOT allow me to cursor down to a blank line under "hello".
Interpret as you like.
My personal practice is to try to ensure text files end with a trailing newline. I just feel there's the least surprise to people and tools with this is the case. I wouldn't treat source files any different from text files in this respect.
Google turns up this:
which, as of this edit, show hits that talk about warnings about a missing trailing newline coming from C compilers, svn (because of diff), diff, etc. I feel there's a general expectation that text files (source files included) end with a trailing newline and least surprising (and less noisy) when they tend to be there.
Finally this is interesting:
Sanitizing files with no trailing newline
Text files should have all their lines terminated by newline characters (ie, \n). This is stated by POSIX, that says that a text file is
A file that contains characters organized into zero or more lines.
A line, in turn, is defined as
* A sequence of zero or more non- characters plus a terminating character.
HOWEVER, all that said, this is just my personal practice. I'm happy to share my opinion to anyone that asks, but I don't foist this on anyone. I don't feel this is something worth mandating, like I say here:
While I'm one whose all for consistency, I'm also against micromanaging every bit of style. Having a huge list of coding conventions, particularly when some of them seem arbitrary, is part of what discourages people from following them. I think coding guidelines should be streamlined to the most valuable practices that improve the -ilities. How much is readability, maintainability, performance, etc improved by mandating this practice?
Here is a good reason for having extra line-break at the end:
If you have a file without line-break at the end, next time the file is edited to add another line, most of merge tools will think that the existing line has changed (I'm 90% sure SVN also does).
In the example below, the line containing “last line before edit” does not have the line break. If we try to add a new line “last line after edit”, as we can see both lines 5 and 6 are marked as changed, but actual contents of line 5 in both versions are the same.
If everyone is following your project lead suggestion, then this would be the result (only line 6 differ from original file). This also avoids misunderstandings during merges.
While this may not look like a big deal, let's say one developer (A) actually meant to change the contents of the last line and another developer (B) added a new line. If not using line-break before EOF, then you have a merge conflict because developer B was forced to also edit the former last line to add a line-break. And... who likes CVS/SVN conflicts?
Have a look at this SO question..
The answer shamelessly stolen from Ralph Rickenbach:
Many older tools misbehave if the last
line of data in a text file is not
terminated with a newline or carriage
return / new line combination. They
ignore that line as it is terminated
with ^Z (eof) instead.
So I figure it's mostly a ghost of the past. Unfortunately, such ghosts can bite you in the tail if you don't properly exorcise them. (Is your build server old and uses older shell scripts for summaries and such things).
Try to cut/paste the whole file.
Something bug in checkstyle or eclipse : )
Aside from the already mentioned valid reasons for having a trailing newline character (possible issues with older tools and diff), here is another way to look at it:
Why special-case the last line by not appending a newline character when all other lines in the file have one?
Sometimes your compiler doesn't parse it correctly:
Error: Reached end of file while parsing
It is just a coding style. Doesn't hurt or help anything. I would not let it bother you it sounds like it is your teams preference to include and empty line. There is not really a good argument against it other than why does anyone care enough to actually add it to checkstyle?
I have never heard of such a requirement.
In fact, I just confirmed that a Java program will run without any compiler/runtime errors or warnings when there isn't a blank line at the end of the file.
This, as some commenters have said, must be a coding style issue. Unfortunately, I can't suggest why it may be important for there to be a blank line at the end of a file in Java. In fact, it seems entirely pointless to me
We had to do this for some C++ code as the compiler generated a warning about it, and we had a 'no error or warnings' policy.
Maybe the issue lies elsewhere... have you a diffing tool have goes haywire or a merge tool that can't handle it?
It's not a big deal really.
Is there a quick way to find all the commented-out code across Java files in Eclipse?
Any option in Search, perhaps, or any add-on that can do this?
It should be able to find only code which is commented out, but not ordinary comments.
In Eclipse, I just do a file search with the regular expression checkbox turned on:
(/\*.*;.*\*/)|(//.*;)
It will find semicolons in
// These;
and /* these; */
Works for me.
Sonar can do it: http://www.sonarsource.org/commented-out-code-eradication-with-sonar/
You can mark your own commented code with a task tag. You can create your own task tags in Eclipse.
From the menu, go to Window -> Preferences. In the Preferences dialog, go to General -> Editors -> Structured Text Editors -> Task Tags.
Add an appropriate task tag, like COMMENTED. Set the priority to Low.
Then, any code you comment out, you can mark with the COMMENTED task tag. A list of these task tags, along with their locations, appears in the Tasks view.
#Jorn said:
I think [the OP] wants to find code that is commented out, not code that has a comment.
If the intention is to find commented out code, then I don't think it is possible in general. The problem is that it is impossible to distinguish between comments that were written as code or pseudo-code, and code that is commented out. Making that distinction requires human intelligence.
Now IDE's typically have a "toggle comments" function that comments out code in a particular way. It would be feasible to write a tool / plugin that matches the style produced by a
particular IDE. But that's probably not good enough, especially since reformatting the code typically gets rid of the characteristics that made the commented out code recognizable.
If the problem is to find commented-out code, what is needed is a way to find comments, and way to decide if a comment might contain code.
A simple way to do this is to search for comment that contain code-like things. I'd be tempted to hunt for comments containing a ";" character (or some other rare indicator such as "="); it will be pretty hard to have any interesting commented code that doesn't contain this and in my experience with comments, I don't see many that people write that contain this. A regexp search for this should be pretty straightforward, even if it picked up a few addtional false positives (e.g. // in a string literal).
A more sophisticated way to accomplish this is to use a Java lexer or parser. If you have a lexer that returns comments at tokens (not all of them do, Java compilers aren't interested in comments), then you can simply scan the lexemes for a comment and do the semicolon check I described above. You won't get any false positives hits for comment like things in string literals with this approach.
If you have a re-engineering parser that captures comments as part of the AST ( such as our SD Java Front End),
you can mechanically scan the parse tree for comments, feed the comment context back to the parser
to see if the content is code like, and report any that passes that test modulo some size-depedent error rate
(10 errors in 15 characters implies "really is a comment"). Now the "code-like" test requires
the reengineering parser be willing to recognize any substring of the (Java) language.
Our DMS Software Reengineering Toolkit underlying the Java Front End can actually do that, using access to the grammar buried in the front end, as it is willing to start a parse for any language (non)terminal,
and this question is "can you find a sequuence of (non)terminals that consumes the string?".
The lexer and parser approaches are small and big sledgehammers respectively. If OP is going to do this just once, he can stick to the manual regex search. If the problem is to vet the code base repeatedly (needed in big organizations), he'd want a tool that can be run on regular basis.
You can do a search in Eclipse.
All you need to search for is /* and //
However, you will only find the files which contain that expression, and not the actual content which I believe you are after.
However, if you are using Linux you can easily get all the comments with a one liner.