[KPhotoAlbum] [PATCH 2/3] SettingsData: Default window geometry calculated

[Michael Witten]

On 24 Sep 2008, at 3:19 AM, Henner Zeller wrote:

> Hi,
>> I'm  somewhat of  a  disciple  of Saint  Knuth  and  his teachings   
>> on
>> literate  programming,  namely  that  code  should  be  considered   
>> as
>> something embedded in documentation (or  at least something that  
>> flows
>> with a discussion). This seemed like a particularly good case in  
>> which
>> to practice such a tradition.
>
> Agreed to some extend. However, if it slows down reading and  
> understanding
> the code, then it is not a good idea.

But it doesn't. In fact it aids, because the comments and code share  
structure.

> A significant slowdown you get by not keeping the same formatting all
> over the code.

That's nonsense.

Consider a long class definition in a header file. It seems logically
nice to have this kind of structure:

#ifndef HEADER_GUARD
     #define HEADER_GUARD
     namespace Namespace
     {
         class SomeClass
         {
             public:
                 int Int;

                 void a()
                 {
                     ...
                 }

                 void b()
                 {
                     ...
                 }

                 ...
         }
     }
#endif

And it makes sense for a really small amount of code. but imagine one
of those member functions is 800 lines into the file; then, it's clear
that having 4 levels of indentation before the function definition
isn't really helpful; it no longer exposes relative structure. In fact,
it might even feel stupid.

My point is, it's only local consistency that's important.

> So if you have good documentation between the lines, you should at
> least have formatting you stick to so that the eye is quick in  
> parsing.

You've trained your eye to be too quick at overlooking other kinds of
structure.

> It would be different if you _always_ enforce that comments are only
> half indented in the code base - then it is simple to read. But having
> two practices in the same codebase is slowing people down reading
> the code.

Again, only local consistency matters.

Also, the issue is not about some rule of indentation. It's about making
whatever is written provide the most useful information. In this  
context,
the code flows with the documentation.

You're compartmentalizing form and function too much. Form follows  
function.
If you set the form first, the function is restricted.

>>> it will be automatically indented to one level by the next editor.
>>
>> By 'editor', I  assume you mean software.
>
> Both. The next person who has to deal with the code and that persons
> editor software.

If a piece of software does reformat thoughtfully formatted text, then
it's probably a bug.

If a person reformats thoughtfully formatted text, I would hope there is
some measure of thoughtfulness in the reformatting besides "this is how
it's done, because that's what my editor does".

>> There is art  and purpose in the indentation I  chose. It lends  
>> itself

>> to the discussion. So, why should  any piece of software be  
>> encouraged

>> to modify these choices mindlessly?
>
> It does only if you tell it to. But I tell my editor all the time to
> take care of the indentation of the line I am currently in so that I
> don't have to deal with that.

Then you're trying to impose mindless formatting.

> I could tell my editor software to only half-indent comment lines if
> necessary ;-)

Again, it's not a matter of a rule to half-indent comments. It's a  
matter
of exposing structure and reason.