Fwd: Global Shortcuts

[Michael Jansen]

On Thursday 06 March 2008 19:03:13 Alex Merry wrote:
> On Thursday 06 March 2008 17:28:57 Michael Jansen wrote:
> > On Thursday 06 March 2008 17:56:15 Andreas Hartmetz wrote:
> > > connect(
> > >         foo, bar,
> > >         baz, blah
> > >        );
> >
> > Do the example correct
> > connect(
> >     this, SIGNAL()
> >     that, SLOT()
> >    )
>
> You can do that in two lines:
>
> connect(this, SIGNAL(),
>              that, SLOT());

If that's the preferred solution i will try to follow that rule. I just want 
to remark that i think my version is more readable and is easier to type. 
Using tabstop width of 4 i just have to do return and tab and 
i'm set. The good thing here is connect has 7 characters so in that case it 
will kust be two tabs. But when connect is for example a function call with 4 
5 characters I must type in a mix of tabs and chars. Thats why i allways break 
directly behind the opening parenthesis. My is typing wise the same whatever s
ize tabstop is defined to be. I told you i developed my styles over some time 
:-).  

I like to discuss over developing guide lines. Have written some myself. But a
s i said i don't care really. Developing for money means adhering to standards 
given. So no problem here.

> I think that would be more in keeping with the spirit of the style
> guidelines.
>
> > > Q_FOREACH (blah, blarg) //it's not in a public header!
> >
> > Explanation please. Q_FOREACH is an macro. Alternatives?
>
> foreach(blah, blarg)
>
> Q_FOREACH is necessary for public headers because they have to compile with
> the compile-time switch that disables the "foreach" alias.

I can't remember what an alias is in c++. Seem to have missed that thing. 
Just checked. foreach is an preprocessor macro too. Sorry i prefer to have my 
macros uppercase. If you show me an developing style guide who says i have to 
use the foreach version i will question it's sense but adhere. Else i keep usi
ng the uppercase version.

> > And judging from the code i stumbled over noone else in kde does to. I
> > have se en each and every style possible. Included using tabs. That's the
> > only coding style i care about. It's an absolute no.
>
> There's some low-level efforts to unify the coding style in kdelibs, at
> least, and I think many people take the view that kdebase should try to
> follow the same rules, simply because it's so central to KDE.

Then make it clearer. And kill the rule that forbids removing tabs from source
s you don't touch If it's ok to change these nonsense.

I slightly annoyed. Not because someone said i could improve my code. The how 
is bad behavior in my opinion. Some of the things he thinks are bad are 
just laughable. Some of them weren't even my code. And judging for some of the 
sources i touched there are bigger problems in the code.

For me there is only one question. Is the code readable and understandable. An
d that has nothing to do where the brackets or parentheses are. 

Mike

-- 
Michael Jansen
Available for contract work ( Development / Configuration Management )
http://www.michael-jansen.biz