TYPO3 Core

Kasper's note on this:
Code clean up is something I or others from the CVS team will
do and your suggestions are not critical. So I suggest we close this
without any change.

Mere code cleanup is never critical as it doesn't change the code functionality - it just makes the code easier to read and maintain. I hope that this patch will reduce their work a bit. In addition, this patch should be applied before the patch in bug 0000981 (I just splitted cleanup and functionality changes into two bugs).

This is not only a cosmetical problem (which I would change of course) but also a wrong assumption - you mainly removed all tabs left to the comments - this is intended and used for the whole project!

So I close this bug and won't change it. If there's anything else which you think should be changed then please read the project coding guidelines (available at typo3.org) first and commit a new patch.

- michael

I've created a new patch against the current CVS. Could you reopen this bug, please?

AFAICT, my patch doesn't violate the Typo3 coding guidelines. Please be so kind and either point me to the corresponding part of the guidelines in case I've missed anything. Escpecially the following parts of the current Typo3 code seem to differ from the guidelines (and from the Sun Java Style guide), and I'd be grateful for a hint (or a corresponding addition to the guidelines):

1. Whether to use a space [guidelines ], a tab [actual code] or nothing [actual code] between an if|while and the opening brace.
2. Whether to use a space [guidelines ] or a tab [actual code] between some code and a trailing // comment (on the same line).
3. Whether to line up a one-line // comment (without any code before in the same line) to the code in the next line [my personal asthetic favorite] or indent it one tab more. If the comment should be indented more than the following code, a short explanation why this style has been chosen would be nice.

I'm sorry but I really don't have time for this right now.

Hey guys,

just digging this one up. Is this issue still valid? If so, please send a patch that fits to trunk. otherwise we can close this one.

I'll have a look at whether I can create an updated patch ...

In the kickoff for 4.3 it's planned to "refactor" the pibase anyway, so where to discuss this to come to an efficient solution?

Resolved with no change required again:

- No further feedback for a long time
- Cosmetic changes to make code fit CGL shouldn't be done randomly in some files but with a script or something that does this globally as soon as a new CGL has been decided. So this specific issue is then obsoleted anyway.