Direction of KDevelop4

[Alexander Dymo]

> I agree with Jen's pragmatic replies. In the real world, programmers tend
> to layout code according to their own taste, and there is no one right way
> to write code. As a professional programmer doing unpaid work on KDevelop,
> I certainly don't appreciate being told how to write comments and layout
> code. I didn't find any of the code the I've maintained in KDevelop
> particularly hard to follow.
>
> A good name for KDevelop4 might be KDevelop4. Calling KDevelop3 'gideon'
> wasn't a particularly good idea in my opinion. I have no idea why we need a
> 'Mission Statement' to give ourselves a sense of direction. We can carry on
> subjecting changes to peer review in the usual way for a KDE project. We're
> more in need of more people 'doing stuff', than mission statements.

Ok, what's about adding "Coding Guidelines" document to the wiki? Roberto?
(the document just states one module=one coding style principle)


=========================
Coding Guidelines

Coding Style:
- Coding style should be kept the same across the whole code of a
KDevelop module.
KDevelop module can be a:
	plugin,
	utility library,
	set of interfaces.
- The initial author of the code has the right to define the coding style.
- The initial author is obliged to add Kate and Vi modelines to each 
source file.
If the author does not have strong personal preferences over the coding 
style (or wants to stick with the default KDevelop coding style), he is
advised to pick following modeline:
// kate: space-indent on; indent-width 4; tab-width 4; replace-tabs on
(--- add vi modeline here ---)
- The initial author is advised to write an section in the module's README
file about the coding style.
This section should contain:
	* Kate/Vi modelines to use in the files,
	* Example code which represents coding style rules that are not
	described by the modeline. Code snippet is:
namespace foospace
{

class Bar: public Base
{
public:
    Bar();
    int foo();
private:
    int m_foo;
};

Bar::Bar()
    :Base()
{
}

int Bar::foo()
{
    switch (x)
    {
        case 1:
            break;
        default:
            break;
    }
    if (isBar)
    {
        bar();
        return m_foo + 1;
    }
    else
        return 0;
}

}
- All contributors to the code should obey the coding style set by the
initial author. This means they are obliged to:
	* stick to the original coding style when making modifications to 
	exising code;
	* use original coding style also when creating new files inside a
	module;
	* add same Kate/Vi modelines to the new files in the module.

-- 
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine