Code Style Guidelines about andlytics HOT 33 CLOSED

I agree, especially with a standard for line length and intent since formatting the code is a real pain when it comes to merging code with different formats.

100 chars sounds fine, probably even 110
As for intent we should definitely use spaces since tabs might differ from systems to system, one having 1 tab = 2 spaces another one having 1 tab = 4 spaces. So I would vote for 4 spaces for indentation.

from andlytics.

Well AOSP (and ABS etc) uses 100 which is why I suggested that http://source.android.com/source/code-style.html

Any views on variable names?

from andlytics.

Didn't know that. So 100 sounds fine.

As for the naming pattern of the AOSP sounds fine.

from andlytics.

I hate mStuff, it soo much MFC :) But that's essentially a religious debate. We should probably stick with the naming in current code, changing everything is not a good idea IMHO. As for formatting, either use the android-formatting.xml from ASOP and reformat the code as you go, or ask the original author to export their formatting rules and use it.

from andlytics.

Yes I do agree it isn't really worth the effort of refactoring the whole thing.

By the looks of the formatting it is the default options from eclipse so I guess we could just use that, would make things easier.

from andlytics.

Would make it easier but we should find at point in time where we do not have any "active" forks and switch to the AOSP formatting with auto format on save. Simply because line length 80 is just killing me in times where most people have a decent screen resolution and wide screen format...

from andlytics.

Sorry for late response, but at this moment I've not much time.
I think that we should use some standard(I do not know about them). May be the best is AOSP due it was though to use in android project and probably it has some features that was defined for these propose.

Once defined a standard, we should follow it without variation by the following reasons:

1. As nelenkov remarks decide some feature will be a religious debate. And we only need decide what standard to use.
2. When somebody adds code, he can view code-styling based on standard, and follow it if he has some doubt.

from andlytics.

Can we agree on this. I want to start on the improved multi-account management soonish (1-2 weeks) which will require quite a few changes. I'll also revise/update my previous commits if needed at the same time.

from andlytics.

I thik we must select and set code style ASAP. And probably reformat all source files. Because on each modification we reformat some lines (eclipse) when insert control points and following diferences comes hardest than it should.

from andlytics.

Sure thing. So for starters, AOSP formatting, spaces, no tabs, line limit 100

Right?

Can someone post a link to the formatter file of AOSP?

from andlytics.

Rewrite of the whole source code seems a lot of work!

from andlytics.

That's why is just mentioned AOSP formatting, spaces, no tabs and line limit 100, so only the formatting is changed and people can rename variables along the way, whenever they change a class.
But at least everyone uses the same formatting so merging stay possible.

from andlytics.

Well re-formatting is not that bad. Once you setup eclipse which only takes a few min, open up every java file and press a key combo to apply the auto formatting. Should be able to do the whole codebased in <15 min ish. Then from then on, everything will be in sync.

If we choose to go to mPrivate style (which I think would really help in some places which have a lot going on and use a mix of local and class level variables), that can be done bit by bit (altought people would be welcome to to that at the same time, at least for the core classes)

from andlytics.

I agree with @willlunniss

Can someone provide a link to the AOSP Eclipse-formmater file? I absolutely don't know my way around AOSP :'(

from andlytics.

What means "no tabs" exactly? For indentation and alignment?
If in a "class" a "function" has a "for" loop with a "if" where i "catch" an exception, i have to hammer 5*8 ( = 40) time space?
Every project has this debate. And changing Eclpse setting is even not possible if you are part more than 1

from andlytics.

Changing the naming convention is definitely a bad idea. Changing the formatting style is not too good either, given that the initial code base is fairly large. But if everyone absolutely hates the current one, well, maybe.

from andlytics.

@fda77 Eclipse will expand tabs to spaces, so no need to hammer like crazy :)

from andlytics.

Using an IDE you would set indent to be 4 spaces, when you press tab, it inserts 4 spaces.

As for what we choose, I really don't mind and still am not sure if it is worth the effort of changing things, i just want it to be decided upon so that commits are done in a standard way.

from andlytics.

Replacing tabs with (4 or 8) spaces by Eclipse is no option for me. All other projects using tabs

from andlytics.

Eclipse can set stiling preferences per project. project->java CodeStyle->Enable spicific
Anybody is not developing with eclipse?

from andlytics.

You can set at least workspace specific formatting options (not sure if they can be project specific).

Well I think we all agree that line length of 100 is sensiable? As for the rest, would it just be easier to leave that.

from andlytics.

Formating all files at once
http://stackoverflow.com/questions/5133781/how-to-format-all-java-files-in-an-eclipse-project-one-time

from andlytics.

On my screen can display 160 chars. And i have no 16:9 or 16:10 display. Why don't use the space? In fact most lines are much shorter

from andlytics.

Because some people don't have the space, especailly if you do side by side comparison, or have debug views open.

from andlytics.

In my display 17'' 4:3 and only one monitor more than 120 will does not fit, but lines longer than 120 are not usual

I propose reformat all files:
Do not wrap line length
Replace tabs by spaces(4 as said AOSP)
Rest of block format etc eclipse default.

Then when coding:
New code try to fit to 100 line length, but if the programmer consider is prettiest longer line don't wrap it.
Of course use 4 space tab
Don't touch old code unless it is ugly due automatic format

I think with this and carefully coding, we will not add dummy diffs

from andlytics.

Same procedure as every ...
Of course use 4 space tab
Wtf? The default is 8! Open a shell type " echo -e "\tx"" and count spaces..
Other way it is hard to see a difference of indentations and alignments.
Btw, using tab (as usual) every one could use a wired custom tab width like 2, 4, 6 or 17. It makes sense to not use spaces.

from andlytics.

Now we are getting into the religious part :) With modern editors/IDEs it largely doesn't matter -- you can set tab width and/or expand automatically, etc. Even git is smart enough to handle differences when merging. That said, the point is to be consistent.

from andlytics.

I habe to agree with @nelenkov the only thing I want is a stand way of formatting, so we all format consistently.

from andlytics.

OK, we will never agree on this so can we just vote.

Mine is for leave it how it is, and clean up any inconsistancies as we go. Specifically tabs, rather than spaces as that is what appears to be in most places.

from andlytics.

I vote for replace at least all tabs in order to avoid false differences.
for f in $(find src/ -name '*.java') ; do expand --tabs=4 $f > $f.tmp && mv -f $f.tmp $f ; done

from andlytics.

Right this has to be decided upon. I've just done two mass formatting opperations on my current branch and recorded the size of the diff generated:

-> All Tabs : 15K lines
-> All 4 Spaces : 23K lines

Therefore, unless anyone really objects, I will mass format the code tomorrow night to use tabs as that is what the majority of the code uses. As for line lengths, I'll split excessive ones.

And we will leave and conform to the current naming standard.

from andlytics.

+1

from andlytics.

It's done, see #154

from andlytics.