Community
Participate
Working Groups
I suggest to change the default line size of the Java Editor to 120. I did a poll in my blog and the majority would like to see this change. http://www.vogella.de/blog/2011/09/06/eclipse-default-line-length-of-80-chars-outdate Comments on Google+ seemed to follow the same pattern: https://plus.google.com/104044918586174763681/posts/EydgeWHdvyX
+1
[lurking]
The line length is controlled by the code formatter: org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_LINE_SPLIT There's no separate setting in the Java editor. The "Java Conventions [built-in]" profile implements http://www.oracle.com/technetwork/java/codeconventions-136091.html#313 and won't be changed unless that document is changed. The "Eclipse 2.1 [built-in]" profile also won't be changed, but we could change the "Eclipse [built-in]" profile. We'll discuss this in the JDT arch call.
Thanks Markus. Changes in "Eclipse [built-in]" would be super. This is the default profile used by the Eclipse IDE and therefore this change would help the users.
-1 I still prefer 80. :)
This can be customized per project. So why should the default value be changed ?
@Olivier: I believe defaults are important as few developers take the time to change them and in a distributed team it is often the easiest to stay with the default settings.
> @Olivier: I believe defaults are important as few developers take the time to > change them and in a distributed team it is often the easiest to stay with the > default settings. @Lars, I agree that defaults are important. But for me, project specific settings are even more important. I blogged about that in the past and it seems that there are still people which rely on workspace's settings. Project settings are shared for all team members. Changing this value will actually affect all users that rely on workspace's settings. With format on save, they will end up with undesired changes.
(In reply to Olivier's comment #24) > @Lars, I agree that defaults are important. But for me, project specific > settings are even more important. +1. If you want your distributed team to all use a particular preference/setting, store it in the project itself.
@Olivier I believe the majority of the user would like to see the change. If they have not setup any project specific setup they will hopefully welcome this change.
(In reply to comment #25) > (In reply to Olivier's comment #24) > > @Lars, I agree that defaults are important. But for me, project specific > > settings are even more important. > > +1. If you want your distributed team to all use a particular > preference/setting, store it in the project itself. This issue is not about having my team particular settings I want them to have. This is about having sane defaults for most users wether they are in a team or they work solo or are just students working on their assigment just starting to learn programming. It is without question that the default of 120 is better for 2011, as the default of 80 was fine back in 2001. Java as a language has changed since 2001. Many people use inline subclassing - and until Java 8 brings us closures this uses a lot of tabs at start of the lines. In schools people teach us to use long names for variables and methods and simple method call with few arguments can take up to 50 characters. Combine that with strings that are not localized (which is how overwhelming majority still uses strings), and you have many simple calls spread out on 4-5 lines instead of 2. You should put in perspetive not only existing "casual" users, but new users that keep coming every day that are downloading Eclipse for the first time. If every time when a change had to be introduced to "casual" users the fear that those users would have "undesirable" changes stopped making that change, then we would never have for example changes in GMail UI, changes of Facebook UI or for that matter changes in Eclipse itself. There would always be vocal minority, but the majority of users would profit from changes, if well thought out. At least for users that would find this change undesirable, you would force them to start using project settings, which you, Olivier, deem as important.
For 3.8, bug 303519 is also in the works. That bug will change line break behavior w.r.t. older Eclipse releases. We should release this change together with that bug so that clients using the default settings only have to adapt once.
@Markus Sounds great. Looking forward to the change.
Please make this 132 columns wide, not 120. We had 80 columns from teletype machines, and 132 characters for wide carriage. A VT100 was switchable into 132 column display. 120 seems to ignore our heritage!
+1 for 120, that's my current setting. I have tried 132 for a while in the past but actually found the lines too long. And comment #28's point should be all the reason needed to go ahead with this.
(In reply to comment #29) > For 3.8, bug 303519 is also in the works. That bug will change line break > behavior w.r.t. older Eclipse releases. We should release this change > together with that bug so that clients using the default settings only have > to adapt once. We don't have a firm plan yet for bug 303519. Should we decide to go with the change of default width, it's better not to depend on that.
I find it astonishing this issue is still open after 2 years. +1 for changing to a reasonable default of 120 or more. Folks still wanting to use 80 characters, can always use project specific settings.
+10 ! and why not 132 :) ?
(In reply to Olivier Prouvost from comment #39) > +10 ! and why not 132 :) ? I found that when I had the navigator and outline panes open it would more often than not still require horizontal scrolling - this was on 1920x1080 resolution and of course is just my personal preference to use 120 over 132 but I think we all can agree that 80 is too low.
-1 Eventually change it to 100, according to: http://source.android.com/source/code-style.html#limit-line-length I also thing that this kind of stuff should not taken as a highly rigid regulation but as guide. In my (java 6) code the larger lines tend to be assignments. I generally use the form: " Type name; name = value " I remember IntelliJ (which I don't use much) recommending that form inclusively. Yet another reference: http://programmers.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width
+1. I would probably like 132 more, but 120 is much better than 80.
Manoj, please take it forward. This is a long standing bug. Let's target an early Mars milestone.
(In reply to Jayaprakash Arthanareeswaran from comment #44) > Manoj, please take it forward. This is a long standing bug. Let's target an > early Mars milestone. +1.
Created attachment 244125 [details] Proposed Patch Patch added to be applied post Luna for early Mars - would recheck the applicability post Luna and call for formal review at that point.
(In reply to Manoj Palat from comment #46) > Created attachment 244125 [details] > Proposed Patch > > Patch added to be applied post Luna for early Mars - would recheck the > applicability post Luna and call for formal review at that point. Note: This has a WIP status now. would run ui tests before upgrading this to "complete" patch status.
(In reply to Manoj Palat from comment #47) > (In reply to Manoj Palat from comment #46) > > Created attachment 244125 [details] > > Proposed Patch > > > > Patch added to be applied post Luna for early Mars - would recheck the > > applicability post Luna and call for formal review at that point. > > Note: This has a WIP status now. would run ui tests before upgrading this to > "complete" patch status. ui tests are green as well. Released via: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f8ddf380a8e7b0e304db0c7d772f1f6806bfc371
Verified for 4.5 M1 using I20140804-2000 build.
Removing the dependency on bug 303519 (See comment #36)
