Code formatting

[gordebak]

I don't know if everybody knew this, but I've found a little gem. This is a code styler:

http://astyle.sourceforge.net/

If you're having troubles staying consistent with your code formatting like me, this may come in handy.

[MyEmail]

Yes, astyle is amazing . I use it on my SVN repos--I have a hooked event that once someone commits changes it checks out a copy, runs astyle one it, and then commits any reformatting changes back to the SVN repo.

This allows my dev's to code in whatever format they like, it just means they will have to re-check it out the next time. After a few annoying collisions because of bad syntax most of them now use the proper syntax in the 1st place .

[Tuxide]

I don't see what's so great about it as it doesn't seem to address any nontrivial issue. This only addresses language syntax and we can make a big deal about it as much as we want to, but in the end it has nothing to do with how your code actually runs. Language semantics is more important. It would be more useful if it supported something like XML, JSON, or even JavaScript where minimizing download time is important.

I use code formatters to clean my work up before I commit, but for the target languages that this tool supports there's no point to making a scheduled task out of it.

[MyEmail]

Quite to the contrary, it forces a project to use the same syntax without anyone having to worry about it. Good syntax leads to good comments which lead to good code (all three are integrally connected), and when its as easy as a 3-command shell script, why not?

[Tuxide]

Quite to the contrary, it forces a project to use the same syntax without anyone having to worry about it. Good syntax leads to good comments which lead to good code (all three are integrally connected), and when its as easy as a 3-command shell script, why not?

I don't see how your argument supports your conclusion; this appears to be nothing more than a tabs-or-spaces tool similar to GNU Indent. Unless this does something else like complains to the user for using Hungarian notation or something, consistency with indentation in code is not going to encourage developers to write more beautiful code documentation. Having an auto-indent task tied to a post-commit hook seems to be only useful if you have people committing really bad looking code, since everyone should be using some indent program in their development environment anyways.

[Knitter]

Having some post-commit task changing the committed code is something I always try to avoid, the code I send must be exactly the code I retrieve.

Nowadays every decent editor and IDE has and indent feature, and most will allow you to specify which rules you want to use in a given project so you can have different rules for different projects.

I think that following the indentation rules, and other coding rules, for a project is something that the developers should respect and abide to, we shouldn't use tools to correct that mistake we should educate the developers.

I usually define a set of rules with the initial developers, everyone that comes after just has to follow the existing rules, if not the code won't be accepted. After the first code review they usually set up their development environment to match the project's coding standards.

So, even though astyle is a nice tool, I think using it to mitigate the fact that you either don't have coding standards imposed or your developers are not abiding by them is the wrong way to correct the problem .

[MyEmail]

This method of hooking astyle to SVN is used all over the open source world--especially linux. When you have dozens of developers there is no way you can guarantee someone commits code compliant with the formatting standard. Hence it is easier to use a astyle-svn hook than it is to constantly police others' work.

@Tuxide:
I think my argument supports the conclusion quite well--astyle keeps the code well-formated, well-formated code leads to better development. If you don't agree with this than I wonder if you have ever programmed before...

@Knitter:
The idea isn't to "make tools format our bad code for us" or to "avoid enforcing good standards". Instead, it guarantees code fits the standard without having to constantly police others' work. It does this in two ways: A) it formats the code if it isn't formatted correctly, and B) programmers dont't use bad syntax because of the annoyance of re-checking out the SVN server after each commit.

Hence it makes developers use the standard--and forces it when they don't--all without any extra work on the project manager. In the end its a win-win situation with a 3-command shell script, so why not?

[Knitter]

In the end its a win-win situation with a 3-command shell script, so why not?

Simply put, because it changes the code that was sent in the commit and I'm allergic to that. If I commit something it must not be changed. I grant that it doesn't really change the code and just commits new changes, still, it's something I don't like to have.

[Tuxide]

@Tuxide:
I think my argument supports the conclusion quite well--astyle keeps the code well-formated, well-formated code leads to better development. If you don't agree with this than I wonder if you have ever programmed before...

Your conclusion is that such a code formatter tool should be used in an SVN post-commit hook, and your argument you are trying to use to support it has nothing to do with SVN and is thus irrelevant. Anyone can check someone's code out, run their own reformatter tool as often as they want to, and document and code away. I do it all the time, and it defeats the purpose of having an SVN post-commit hook for it since I would end up undoing it anyways.

[MyEmail]

@Knitter: So long as you follow the standard astyle won't make any changes.

Tuxide: When you pull parts of argument out of context, yes. When you address my argument as a whole, no. The conclusion was that a FOSS project with many developers benefit from such svn-astyle hooks because it ensures the code fits standards without having to police it. Because the code is guaranteed to fit the standard, it is guaranteed to be well-formatted. Well-formatted code leads to better development. Hence by using astyle-svn hooks it betters development (+ is easier of team leads).

Just because you have an alternative method of formatting code doesn't defeat my argument (fallacy). Lets say we where arguing how to peel an apple. There are obviously many methods of doing so--knife, potato peeler, boil it and the skin falls off, etc. Like the SVN-astyle hook being a tool to accomplish the goal of good code, a potato peeler is a tool for accomplishing a peeled apple. Hence I can argue that peeling a apple with a potato peeler is a effective method. By concluding that my svn-astyle argument is invalid because you have an alternative method of reaching good code is the same as saying that my argument of using a potato peeler is invalid because there are alternative methods such as a knife. Obviously this is incorrect, as the argument of using a potato peeler is a very valid way of skinning an apple.

Likewise the argument of using svn-astyle hooks is a valid argument for achieving good code just the same as using reformatting tools separate from svn.

[Tuxide]

I think you completely misread my comments. The fallacy I'm pointing out is implying that well-formatted code leads to better development justifies using a formatter in an SVN hook. I never said using a formatter doesn't lead to better code. So now we are back to the original question: Why use such a tool as an SVN hook in the first place?

My conclusion was that this is trivial and isn't worth policing; however I'm also inclined to accept that this may be considered on a per-project basis instead of making a hasty generalization over this. Maybe some of the committers do suck. But in general I tend to think forcing my good intentions on someone else is no different than an evil act. Being able to find value in how some person writes code instead of ignoring his coding style completely leads to liberty for everyone.

[MyEmail]

The fallacy I'm pointing out is implying that well-formatted code leads to better development justifies using a formatter in an SVN hook.

@Tuxide: I understood you perfectly, in fact I understood your argument better than you--which is why I pointed out the fallacy which you seam to be missing. You make it sound as if it is a sin to use a SVN-astyle hook and that I must "justify" it , when in all actuality it is just a method for reaching good code. So it is fallacious to assume that the need for well-formatted code is a justification for using a svn-astyle hook.

[Tuxide]

I haven't felt obligated to answer directly to a lot of the things you've said because of the way you've been trying to make a straw man out of me on this thread. You've been trying to shift the burden of proof onto me by pointing out fallacies I've never made in the first place, and I know better than that. All I ask for is a non-trivial conclusion that is relevant to and directly justifies using a code formatter in an SVN hook, but if you're going to continue mincing my words the way you have been then there really is no point in speaking to you.

[MyEmail]

you've been trying to make a straw man out of me on this thread

If you feel that way then it is too bad. I am merely confused as to why you are incapable of deriving my argument's conclusion--It is very simple and put in straightforward manner in my posts.

Let me reiterate in order to make sure you get it:

1. Well-formatted code leads to better development.
2. A method for achieving well-formatted code--and in turn better development--is that of a svn-astyle hook. This consists of a 3-command shell script that can strongly encourage good code formatting and force it when necessary. It requires no work from the team-lead, project manager, or other programmers. This is especially useful for large projects with many developers. It is even more useful for open source projects who cannot enforce compliance to the standard.
3. Other methods require considerably more time & effort and don't guarantee compliance to the standard.
4. While other methods can achieve the same goal the svn-astyle hook is the most effective method. This is because it guarantees the standard is met and requires no extra work, while other methods are incapable of yielding such results.
5. Because the svn-astyle hook is the most effective method it should be used in projects at the digression of project leaders.

Conclusion: Using an svn-astyle hook produces well-formatted code with no extra work, which in turn leads to better development. The same can be achieved using other--less effective--methods, but because the svn-astyle method is easier and more effective it should be favored over such methods.

All I ask for is a non-trivial conclusion that is relevant to and directly justifies using a code formatter in an SVN hook

Since you where unable to derive it for yourself I provided you with a summary of my argument above. I took special care to put it as simple as possible so you can understand both the argument and the conclusion.

As you can now see, using a astyle-svn hook is very easy and very beneficial. With such benefits achieved with such ease, why not?

[Tuxide]

I'm not too sure what other methods you're referring to, but I schedule a variety of quality management and reporting tools to run such as Cobertura, Sonar, Checkstyle, etc. I guess we can agree to disagree here. To me, scheduling a code formatter is trivial and doesn't really add anything that I don't already have as far as quality management goes, and the tabs-or-spaces argument--from a syntactic point of view--is a classic example of Wadler's Law.

[charlie]

1. Well-formatted code leads to better development.

I'd call that an:
1. an assumption (no matter how logical it sounds)
2. subjective - what is "well formatted"?

Consistent formatting is more important. Yes, this is a way to enforce consistent formatting but I agree with Tuxide, what goes in should be what comes out. With a commit hook, you'd have to commit then update, right? Which may lead to frustrating situations if you forget to update and have to resolve a boat load of conflicts.

[MyEmail]

@Charlie:

Its not an assumption, it comes from years of experience--I have seen how nasty-looking code can harm a project. In fact, I can attribute the root-problem of many dead-FOSS projects to that very cause.

Any developer experienced in team-development knows that he/she must ALWAYS update their local copy after a commit, before beginning more work. So the "frustrating situations" you are referring to are from bad development practices--not from the astyle-svn hook.

@Tuxide:

I think the only reason you disagree is because you lack experience--you haven't been in those situations where astyle-svn hooks come in handy, hence you think it is worthless. Trust me--when you finally bump into such a situation atyle+svn will suddenly look very appealing.

[Tuxide]

No, I disagree because this is just making a big deal over the color of the bike shed. I've had job interviews where they ask questions like "tabs or spaces" and "why", and the response they look for is the one coming from a semantic point of view, not a syntactic one. Either way, for any project that already exists, I assume that the syntactic argument is a solved problem.

Also, I don't see how the tool astyle particularly adds anything that I don't have already. I can just force a build to fail in Jenkins if the code doesn't comply to a certain coding style. If astyle supported more languages besides three or four, then my opinion on this might be different.

[MyEmail]

No, I disagree because this is just making a big deal over the color of the bike shed.

If its so trivial as you claim, why stay here and argue?

Also, I don't see how the tool astyle particularly adds anything that I don't have already.

Which is exactly what I was saying--you lack the experience of when are where it useful, hence you think it is worthless.

[Tuxide]

Well, I've been trying to make a decent effort in finding value in the opposing position, and the only value I've found in it is when you're working with a team of novices who don't know better. That's why I've been pursuing a more direct, relevant, and non-trivial answer.

[MyEmail]

So therefore people who prefer different coding formats are suddenly considered "novices"?

I would beg to differ, as this is used all over the web both for small FOSS projects and large corporations (google it). Even if my testimony is of no value to you, perhaps the countless other people who use such methods is? Just maybe?

[Tuxide]

I don't know how you imply such a thing, but once again you are trying to misrepresent what I say, like you've been doing lately. Any rational thinking person can see that you're not even refuting my remarks, but those of a straw man. Considering you've been doing that throughout this entire thread, I don't know how it's even possible for anyone to have a decent conversation with you, like I've been trying to. You seem to have a basic grasp on argumentation theory, so I think it's fair to assume you're making fallacious arguments on purpose.

[MyEmail]

Solid real-world examples are fallacious arguments? Huh, I think that fallacious--How ironic . If you feel a straw man it is hardly my fault as the entire basis of a debate requires emotional separation from the topic and outcome. Since you seem to be implying you are educated in argument theory surely you can see past this and provide an adequate argument--something more than discrete complaining preferably.

[Tuxide]

Again, you're arguing with a straw man. Stop mincing my words.

[MyEmail]

As I explained in my previous post if you feel a "straw man" its your own darn fault. Perhaps it was how flawed your argument was. Perhaps your constant complaining. Perhaps you feel this way because there is no competition in this argument, and you have nothing better to contribute the whining. Who knows? I don't, but one thing is for sure--its your own fault.

And its really too bad your incapable of debating. Since it is blatantly obvious you aren't going to contribute anything other than complaining, could you leave this topic so others can enjoy the debate? Thank you.

Thank you.