Mindre kod, mer struktur

I väldesignad kod ser man ofta att mängden sammanhängande (jag använder en eufemism sedan ”procedurell” blivit ett skällsord) kod går mot noll, och mängden strukturelement mot oändligheten. Med ”strukturelement” menar jag språkets definitionselement — för typiska OO-språk skulle det vara klass- och metoddefinitioner.

Den här tendensen förstärks t.ex. av objektorienterade designmönster, som i sin iver att utnyttja polymorfism ökar antalet klasser för att kunna minska mängden villkorslogik.

Se på ett litet C++-program:

class Greeting
{
public:
Greeting(const std::string& target)
: m_target(target)
{
}

void Utter(std::ostream& channel)
{
channel << "Hello " << m_target << "!"; } private: std::string m_target; }; int main() { Greeting greeting("Dolly"); greeting.Utter(std::cout); return 0; } [/sourcecode] Vi har egentligen bara tre rader procedurell kod här, implementationen av Greeting::Utter och användandet av Greeting i main. Det betyder att 20 rader består av strukturelement. Av dem innehåller i sin tur tre (Greeting, Utter och main) namn som skänker någon sorts betydelse till programmet. Resterande 17 är mest syntaktiskt oväsen.

Fast jag hade inte tänkt smutskasta C++ & co här, läs Fowlers artikel för mer tankar om olika språks uttrycksfullhet.

Snarare vill jag kasta ut en fundering: skulle man kunna använda ration mellan strukturelement och kodelement som ett mått på designkvalitet? Något säger mig att det skulle funka ganska bra för språk som C++, Java och C#…

3 thoughts on “Mindre kod, mer struktur

  1. Anonymous skriver:

    Kvoten är intressant, men IMHO max halva sanningen. Visst har du väl kikat på Javakod du aldrig sett förr, hittat en miljard interfejs, klasser och konfigurationsfiler och efter en halv dags huvudkliande insett att samma sak hade kunnat göras med en tiondel så många strukturelement?

  2. Kim Gräsman skriver:

    Just Javakod har jag klarat mig ifrån, men den C++-kod jag snubblar över brukar snarare lida av det motsatta problemet: extremt låg sammanhållning.

    Men visst kan man skriva dålig kod som ger en hög kvot. Liksom de flesta metrics kan man inte ensidigt försöka maximera dem utan att hjärnan är med.

    Jag tror att om man skulle beräkna kvoten för 10 subjektivt ”bra” kodbaser och 10 subjektivt ”dåliga” skulle trenden vara att kvoten var högre för de ”bra”.

  3. […] här angränsar till min teori om ration mellan kod- och strukturelement som mått på kvalitet, men istället för att, som undertecknad, blankt hävda att mer struktur är bättre ställer sig […]

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s