ID:151494
 
I've noticed that some people have criticized me for my otherwise "unreadable" code. What makes it so unreadable is the fact I use little to no spacing and try condense as much as possible into fewer lines which ends up being extremely cluttered. I do this because I find it easier, and I have absolutely no problem reading something I've typed down when it's all smooshed together. If people are going to be viewing the source of something I'm doing it would be of my best interest to of course, make it readable and easy on the eyes.

Of course there's also the problem of sometimes ME getting unorganized with all my code condensed so much. I have to study not only the context of the code I've written when I forget something, but also the syntax. There's also of course the huge pro to condensing everything; it's faster, and easier to type down at first. Here's an example of what a typical person would consider "readable":
switch(protection)
if(YES)
src << "You aren't a dirty pig!"

if(NO)
src << "You are a dirty pig!"

if(WHAT_IS_PROTECTION)
src << "What is protection?!"
var/list/responses = list()

for(var/mob/M in world)
spawn()
responses.Add(input("What do you think is protection?") as text)

sleep(500)
src << "The populace thinks \"[pick(responses)]\" is protection!"


And here's MY normal approach:

switch(protection)
if(YES) src<<"You aren't a dirty pig!"
if(NO) src<<"You are a dirty pig!"
if(WHAT_IS_PROTECTION)
src<<"What is protection?!"
var/list/responses=list()
for(var/mob/M in world)
spawn() responses.Add(input("What do you think if protection?") as text)
sleep(500)
src<<"The populace thinks \"[pick(responses)]\" is protection! Oh and your code is UNREADABLE AAAUURGH!!"



There's a significant difference in the amount of time it took me to type the condensed version. But the real question is; which is more practical/efficient in the long run?
Lets say you have proc called DamageHealth. You call it to lower players health and it'll calculate damage based on mobs Strength, Endurance, Defense, Skills, Equipment.

With your approach it would be lets say 4 lines for each calculation (Strength, Endurance, Defense, Skills, Equipment) ending up in 20 lines.
Later on when something happens, it'll be hard to determine where is what. (at least for me)

With that "readable style" you would end up with 25-30 lines, but later on you'll be able to tell difference easily where calculation for Defense begins, and where it ends, as you'll have spacing which will separate these calculations.
In response to Ripiz
I still add lines between code and add /* notes */ and //notes sometimes. I only do it when I'm dealing with lengthly procs but not exactly in situations like you described.
You said you "try" to. This implies effort on your part. So how can you "find it easier"?
If there were a significant difference in the time it took you to type them I'd imagine you just aren't used to typing spaces, newlines, and tabs. I count 15 keypresses worth of difference, most of which are spaces. What is your typing speed? Otherwise, either approach seems quite readable and both are valid--I prefer a more readable style myself. In the grand scheme of things though, it shouldn't take you much longer to organize the code a bit. If you're ever working with someone else, revisiting old code, or dealing with copious amounts of code you may consider a cleaner style just to smooth things along.
maybe next time, certain people can "try" to actually respond to your post instead of making remarks.

Condensing code has it's pros and cons, if you can understand it just fine and you don't think anyone else will be looking at it, then go ahead and condense away, or if you know others might look, but you don't want them to focus on that bit of code too much and explain it a simpler way with a comment.

The biggest con to condensing is the possibility that you end up losing your place, though not likely, it IS possible.

The biggest pro to condensing is file-size, while you wont save a lot, condensing a your code can shave a good 5-10% off the general file size. Reason being that tabs are special characters and have a larger bit size than spaces. If you're packaging this for library use, it's a bad idea, however if it's being packaged as a demo, or something you wouldn't expect to be modified, then condense it all you'd like.

If you think about it, procs are a way to condense multiple instances of a string of code into one command. Why? Mainly, ease of use. but it can impact file size if the project is large enough.
Duelmaster409 wrote:
And here's MY normal approach:
> switch(protection)
> if(YES) src<<"You aren't a dirty pig!"
> if(NO) src<<"You are a dirty pig!"
> if(WHAT_IS_PROTECTION)
> src<<"What is protection?!"
> var/list/responses=list()
> for(var/mob/M in world)
> spawn() responses.Add(input("What do you think if protection?") as text)
> sleep(500)
> src<<"The populace thinks \"[pick(responses)]\" is protection! Oh and your code is UNREADABLE AAAUURGH!!"
>

There's a significant difference in the amount of time it took me to type the condensed version.

The condensed version should take less time to type, but that's not a good thing. Computer games don't take months to develop because you have to type a lot of code. If that was the case, the best programmers would merely be the people who type the fastest. More time is spent thinking of what code you need to write and modifying the code you've already written.

The time spent writing the initial code makes very little difference. Writing messy code can cost you more time in the future. In your example the compact code has 7 fewer line breaks and 3 less tabs. How much time could this save you? Being generous this might save you one second.

But the real question is; which is more practical/efficient in the long run?

Small amounts of unreadable code (like what you posted) are okay. You can deal with its quirks. Instead of relying on clean code and good comments to understand what code does at a glance, you rely on remembering what the code does and how it's laid out. For a small chunk of code you can handle that, but when this code is part of a project that is growing it will become harder to remember these things.

When you can't remember how the messy condition of the if statement works, you'll make a mistake and introduce bugs. When you can't remember what events take place in a 60-line proc, you'll put new code in the wrong spot and introduce bugs. When you can't see how your complex damage calculation works because it's crammed into one line you'll put the "*2" in the wrong spot and mess up the calculation.

A bug introduced by compact code is going to take you minutes, possibly hours, to fix. The time saved by writing compact code is on the order of seconds. Any problem that your unreadable code gets you into will instantly undo any benefit you thought the compact code had.
From an efficiency standpoint, it really doesn't make much difference either way. If it were to be, you'd expect many less C style-guides for example, and you wouldn't expect companies to produce their own style-guide for a given language, but use a known "good" one verbatim.

The argument of ease of writing is a little bit like that of "How important is WPM?" in essay writing. For suitably involved essays at university, I found most of my peers would spend about 1 - 2 hours on a 1000 word essay. These people had a rather varied known WPM: 40, 80, 100, 120 etc and yet they all took (more or less) the same time to write a given essay.

We'd discussed this idea amongst ourselves one day, and established that the reasoning was fairly straight-forward. The bulk of the time we spent on essays was not transcribing literally thought words onto paper, it was establishing the content of the essay and the choice of those literal words and phrases. WPM did naturally speed up a part of the process, but that part was not the big time consumer for writing an essay.

The idea of course cropped up again when I started work in the industry. I happen to be effectively a two-finger typer, which seems to shock people considering how much I use a PC as part of my job. But the same goes, the bulk of my time on writing code isn't the literal process of entering it into the PC, it's establishing and verifying the logic I'm going to use, referencing other material etc. I would guess that the literal transcribing process takes up 10% or less of my time.

---

Now, what a style-guide does tend to provide however, is uniformity and hopefully some readability as a consequence. Interesting I personally feel both of your examples lack that. Here's some commented versions with my thoughts:

switch(protection) // About to enter a block.
if(YES) // About to enter a case block.
src << "You aren't a dirty pig!"
// Case block complete, the change in indent probably would've sufficed.
if(NO)
src << "You are a dirty pig!"
// src << "" is nice, the spacing breaks operators and other constructs logically.
if(WHAT_IS_PROTECTION)
src << "What is protection?!"
var/list/responses = list()
// What does this whitespace signify?
for(var/mob/M in world)
spawn() // Spawn is a block statement, so fair enough.
responses.Add(input("What do you think is protection?") as text)
// Again, what does this signify?
sleep(500)
src << "The populace thinks \"[pick(responses)]\" is protection!"


switch(protection)
if(YES) src<<"You aren't a dirty pig!" // Operators run on into constructs, may be more difficult to discern at a glance with other operators.
if(NO) src<<"You are a dirty pig!"
if(WHAT_IS_PROTECTION) // Inconsistent flow, I now have two forms of case statement for reading, instead of one.
src<<"What is protection?!"
var/list/responses=list() // Much the case as the operator bit.
for(var/mob/M in world)
spawn() responses.Add(input("What do you think if protection?") as text) // you'd introduce a second form syntactically if you needed a bigger block.
sleep(500)
src<<"The populace thinks \"[pick(responses)]\" is protection! Oh and your code is UNREADABLE AAAUURGH!!"


Now what you pick for your style-guide is really none of my concern, however this should hopefully give you food for thought on the role syntax plays in readability, in a more analytical sense. As for efficiency, the time taken to write literal code is probably among the lesser of your worries.
In response to Forum_account
If anyone is having problems reading that condensed code then they need to go back to programming 101. Maybe if you were attempting to read it in WordPad that would be understandable, but compilers have fancy formatting that make line after line of code easy to read. I find it much simpler to read a 10 line proc in a single screen, than attempting to scroll through that same proc spaced out over 100 lines.
If you somehow require white space to know when an if() ends, especially in BYOND, then its back to programming 101 for you as well, especially if the lack of white space is somehow causing you to put code in the wrong place.
Comments are pretty bad as well, and should be unnecessary if the code is well written and the programmers actually know what they're doing. If you have to write down a comment to describe what a variable is for, you have obviously given that variable a poor name - fix the actual problem, instead of just adding some comment in hopes of remembering things later.
Really though, consistent standards and conventions are whats most important. This applies to everything, not just white space. Don't have half your procs with white space everywhere, and others with lines of straight code, keep variable and proc names consistent, keep things generally well organized, etc. Efficiency > Readability >= Functionality
In response to Falacy
Falacy, I really have to know: how do you manage to be so consistently wrong?
In response to Garthor
Garthor wrote:
Falacy, I really have to know: how do you manage to be so consistently wrong?

As usual, the worthless comments around here that equate to "YOU ARE WRONG" don't accomplish much. What do you have a problem with now? Am I just using words that are too big for the community members around here to understand, or is there some other reason that you all think I'm wrong on a regular basis when stating blatant facts?
Using indentations in DM is a functionality that allows you to eliminate the pointless white space implied by {}s in other languages like C++.
In response to Falacy
See, I don't really have anything to prove, gain, or accomplish by explaining how it is you are wrong. I am simply making the observation that you are, once again, oh so very wrong.
In response to Falacy
If anyone is having problems reading that condensed code then they need to go back to programming 101. Maybe if you were attempting to read it in WordPad that would be understandable, but compilers have fancy formatting that make line after line of code easy to read. I find it much simpler to read a 10 line proc in a single screen, than attempting to scroll through that same proc spaced out over 100 lines.

It's mostly not hard to understand condensed code, but such code is still (usually) less intuitive and organized. The simple addition of whitespace, tabbing and whatnot makes for a much easier read. When your code is easily readable, bugs can be spotted more easily, and you can program more efficiently (as you take less time to find your way through your source code). In contrast, you will have more difficulty spotting bugs inside a disorderly mess of condensed code.

Comments are pretty bad as well, and should be unnecessary if the code is well written and the programmers actually know what they're doing. If you have to write down a comment to describe what a variable is for, you have obviously given that variable a poor name - fix the actual problem, instead of just adding some comment in hopes of remembering things later.

There is a school of thought that claims comments should only be used when utterly necessary, and code should be completely self-describing. That is, however, arguable: ideally code should be self-describing, but when you end up with variables such as "y_position_Where_object1_collided_with_box1" (which even with the best naming scheme and most careful programmer is bound to happen occasionally), it might just be better to help yourself to a comment. Furthermore, this argument excludes comments meant for describing systems. No matter how intuitive your code is you would probably have a difficult time understanding a complex algorithm after not accessing it for a period of time (surely you've experienced that?).

Efficiency > Readability >= Functionality

I would argue the order should be, in almost every case, the exact opposite!
I tend to write very large blocks of code, so for me, condensing code is more efficient. With a large block of condensed code, the content per 'page' is higher, so you can see more info without having to scroll back and forth through a dm file. That being said, I use tabs liberally to line up key elements and to make things more readable.

Something you may find useful is {}, which allows you to condense things even more. Not that you'd want to do so in this case, but just as an example, you could condense your lines
        sleep(500)
src<<"The populace thinks \"[pick(responses)]\" is protection! Oh and your code is UNREADABLE AAAUURGH!!"

into
        {sleep(500);src<<"The populace thinks \"[pick(responses)]\" is protection! Oh and your code is UNREADABLE AAAUURGH!!"}


Here's a real-world example using ability definitions:
    fire/   {ch = 75; cm = 25;  rc = 10;  d = 3.0;   f = 0;   tp = "a dmg";   name = "Fire";  ic = 'Fire 1.dmi';   sfx = 'Fire.wav';   e = "fire"}
ice/ {ch = 75; cm = 25; rc = 10; d = 3.0; f = 0; tp = "a dmg"; name = "Ice"; ic = 'Ice 1.dmi'; sfx = 'Ice.wav'; e = "ice"}
light/ {ch = 75; cm = 25; rc = 10; d = 3.5; f = 0; tp = "a dmg"; name = "Light"; ic = 'Light 1.dmi'; sfx = 'Light.wav'; e = "light"}

This shows just 3 lines out of about 120. All of the condensed content is shown on just over 2 'pages', where before I condensed it, the information was spread over dozens of pages.

Here's another example, where simple expressions are condensed, allowing me to fit more content on a single page:
for(var/turf/T in path) if(T == dest_turf) {in_path = 1;break}
In response to Toadfish
Toadfish wrote:
Efficiency > Readability >= Functionality
I would argue the order should be, in almost every case, the exact opposite!

It doesn't matter how pretty your code looks; if it takes it 10 minutes to compute 2+2, then you should head back to the drawing board.
Readability should almost never be sacrificed for functionality (and vice versa). If the case even arises, then you're probably doing something wrong and should look for a better way to handle it.
A programming language is just like English, or any other language. Once you actually know it, and its properly written, reading through it should take no effort at all.

Gakumerasara wrote:
Something you may find useful is {}, which allows you to condense things even more. Not that you'd want to do so in this case, but just as an example, you could condense your lines

Using {}s in that first example you posted wouldn't be necessary. The ; alone would yield the same results. The last example is a more appropriate use of them.
In response to Falacy
I find it interesting when opposing schools of thought collide. The problem seems to be that either side likes to argue their points without giving reason--mostly they just call everyone else stupid. I feel a healthy middle-ground is generally an adequate solution. It's not about which is better or more important, good code would have all the qualities mentioned. That is, code that is complex, yet elegant and easily read is what should be sought. When you take a difficult algorithm and make it work, work well, and read well is when you know you're doing things right. Once again, none of this matters as much if you're working alone on some tiny BYOND project. When readability and organization becomes important is when you have a team of programmers that are working with each others' code. As far as condensing code so as not to have to scroll through pages of code goes, you're doing it wrong already. For one, most projects contain more than a single screen height of code, so you'll be scrolling a lot anyway. Secondly, algorithms should likely remain broken down into smaller algorithms. Having several hundred lines of code in a single proc/verb is a no-no.
In response to Falacy
Falacy wrote:
It doesn't matter how pretty your code looks; if it takes it 10 minutes to compute 2+2, then you should head back to the drawing board.

It doesn't matter how quickly your code computes 2+2: if it needs to compute 3+3 and nobody is able to understand it to change it then you've got a worthless hunk of junk.

Readability should almost never be sacrificed for functionality (and vice versa). If the case even arises, then you're probably doing something wrong and should look for a better way to handle it.

This works just like Communism: in theory.

A programming language is just like English, or any other language. Once you actually know it, and its properly written, reading through it should take no effort at all.

And, just like English, a passage taken at random from a book is going to be rather meaningless without somebody giving you clues as to the context. Clues like - oh hey - comments.
In response to Falacy
Falacy wrote:
Efficiency > Readability >= Functionality

That is entirely backwards. If you don't know what ">" means you should go back to whatever comes before "programming 101".
In response to Falacy
Falacy wrote:
A programming language is just like English, or any other language. Once you actually know it, and its properly written, reading through it should take no effort at all.

To extend the metaphor, if you open a book to an arbitrary page and begin reading you'll have no idea what's going on. It's not because the book is poorly written, but that there's more to a story than the immediate context.

You've clearly never worked on a large project. You can deal with a small, disorganized project because you can keep things straight in your head. You know what code does just from a quick glance because your project is small, you're familiar with the details. In a significant project you won't be able to remember all of the details and you'll need to rely on comments and other things.
In response to Falacy
Falacy wrote:
Gakumerasara wrote:
Something you may find useful is {}, which allows you to condense things even more. Not that you'd want to do so in this case, but just as an example, you could condense your lines

Using {}s in that first example you posted wouldn't be necessary. The ; alone would yield the same results. The last example is a more appropriate use of them.

It's not necessary, but for someone who has never used {} before, it's a good introduction to the concept.
Perhaps you'd be happier with an example like
if(a==b) {c=d;sleep(e);return f}