A brief look at plugin line counts

[Majiir]

Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.  Bill Gates

Keeping the above in mind, you may find the following table interesting:

[table]

[tr][td]

Name

[/td][td]

Version

[/td][td]

Files

[/td][td]

Lines (Code)

[/td][td]

Lines (Comment)

[/td][/tr]

[tr][td]MechJeb2[/td][td]2.1[/td][td]68[/td][td]56522[/td][td]23041[/td][/tr]

[tr][td]Lazor System[/td][td]31[/td][td]49[/td][td]14471[/td][td]3146[/td][/tr]

[tr][td]Kerbal Multi Player (KMP)[/td][td]0.1.3.1[/td][td]26[/td][td]9551[/td][td]1040[/td][/tr]

[tr][td]Kerbal Attachment System (KAS)[/td][td]0.4.4[/td][td]24[/td][td]8254[/td][td]307[/td][/tr]

[tr][td]KSP Interstellar[/td][td]0.8[/td][td]46[/td][td]7116[/td][td]288[/td][/tr]

[tr][td]kOS[/td][td]0.9.2[/td][td]51[/td][td]6565[/td][td]803[/td][/tr]

[tr][td]Ferram Aerospace Research (FAR)[/td][td]0.11[/td][td]14[/td][td]6480[/td][td]1106[/td][/tr]

[tr][td]RemoteTech2[/td][td]1.2.6[/td][td]50[/td][td]6019[/td][td]143[/td][/tr]

[tr][td]Kethane[/td][td]0.8.1[/td][td]34[/td][td]3810[/td][td]41[/td][/tr]

[tr][td]Extraplanetary Launchpads[/td][td]3.4[/td][td]4[/td][td]821[/td][td]95[/td][/tr]

[/table]

Line counts were computed with the cloc v1.58 utility. Only counts for C# code were used. The mods listed were arbitrarily selected.

[PringleMan]

snip

Majiir, by your metrics, you have one of the worst ratios of comments to total lines of code something along the lines of only 1% of your lines are comments.

However if I recall your code it not open source? Because if so it does not really matter that much, since you need only remind yourself.

[Guest]

Looks like cloc doesn't differentiate between different bracing schemes; you can probably cut out a good 5~10% of the lines from any plugin that isn't written in 1TBS

Majiir, by your metrics, you have one of the worst ratios of comments to total lines of code something along the lines of only 1% of your lines are comments.

Majiir is pretty good at writing self-documenting code, the Kethane source is pretty easy to follow even without comments.

Edited November 26, 2013 by regex

[Majiir]

Majiir, by your metrics, you have one of the worst ratios of comments to total lines of code something along the lines of only 1% of your lines are comments.

Indeed.

Most Kethane code is either so simple commenting would be redundant (and even harmful) or so complex that no amount of commenting would make the code comprehensible. The geodesic grid falls into the latter category. Some of the grid algorithms actually can't be documented (yet) because I derived them empirically. I'll have to reverse-engineer my own work in order to properly document it. Normally this happens because code is undocumented and the original thought process has since been forgotten, but in this case, I never had an understanding of why these algorithms work. I had planned to develop the new grid code more formally before deploying it, but the raycast performance issue presented a need. Pro tip: don't professionally develop software this way unless you're in some kind of breakneck startup environment.

[Nuke]

easy to read code doesnt need no comments. i still comment every 3rd line in my code though, just because i have a horrible memory.

unfortunately my coding skill hasn't bled into ksp yet. im better at starting with nothing and making something, than starting with an existing framework and making something. the former i get neat, consistent code that makes sense to me, and the later its just 90% workarounds, the useful code that makes sense is lost in a sea of dirty hacks (just look at the source to my freespace scripts, its disgusting).

Edited November 26, 2013 by Nuke

[tom1499]

He he he, half my code I can't understand anyway, I just keep writing until it works and don't dare stop lest I forget what was vaguely defined in my head.

[taniwha]

Indeed, excessive comments can cause more harm than good (especially if poorly written (eg, teaching grandma to suck eggs)). IMO, comments are best reserved for explaining why something is done. How is to be left to the code itself. Then there's function docs (eg, for doxygen). they're a real pain to maintain, but they are useful for APIs.

Shut up and let your code do the talking. If it's unintelligible, chances are the computer's confused too .

[dr_jt]

Indeed.

I'll have to reverse-engineer my own work in order to properly document it. Normally this happens because code is undocumented and the original thought process has since been forgotten

I'm a developer by profession and I've been told one of my 2013 goals is to document all my programs and code. What a horror to have to backward engineer my stuff so that I can document it. The other problem is trying not to rewrite code when I see something and think, "what the hell was I thinking when I wrote that?" A couple of weeks ago I came across a section of code that did nothing. It was a complex routine to calculate a value. Right after I did all the calculation I went and grabbed a value from a database table and overwrote the value I just calculated. Why did I write all the code just to over write the value? I'll never know because like you say.

the original thought process has since been forgotten