Why do asset makers advertise "lean code"?

I don't know why, but I see this time and time again. Asset makers in Unity seem to love advertising their product as having "lean code".
"Less than 400 lines per code file!" I've seen some products advertise.
I guess the assumption is that less code = fast code, but logically this isn't the case. I can have a billion lines of code in my game, but I'm not executing the whole billion at once, am I? I'm executing little bits of it at a time. So, the total amount of code has absolutely no bearing on performance.

So why do they do it? What does lean code actually mean, and why is it so often used for marketing?

 

I'd probably say it's so the code is easy to read and navigate- rather being convoluted and messy.

 

Hm, maybe, but lean still doesn't necessarily mean easy to navigate. It could just mean there's less to navigate.
A huge amount of code can still be well structured and clean.

 

I agree its an odd word to use. Better to advertise "clean and structured" in my opinion.

 

"Lean code" could also mean not a lot of features, or at the very least only the important features.

 

Having bought a few assets where the code was a complete mess, with thousands of lines all in one enormous Update function, I appreciate when an author mentions "lean code" because to me it at least implies that they have some experience coding and put in a little effort to make it readable. I think "lean code" is just a nice way of saying "My code isn't a hideous web of arcane gibberish that will melt your brain".

 

Marketing buzz words imo. Using Windows 7 right now, it seems like a popular OS. So does Windows XP. I doubt they've lean code.

 

I should think "clean code" is a better term that means what you're looking for IMHO

 

Because lean is the opposite of fat, which is often viewed negatively.

 

I like lean well organised code. I don't want some messy pile of .js rubbish. I particularly loathe .js assets these days.

 

Marketing only. Every programmer knows a recursive function appears to be the 'leanest' but actually isn't.

I want code that looks that a human has indented it to be easy to read by humans. You often see code with { braces on the same line as a control or function statement 'showing how efficient' they are by not adding the Newline and the Indent. Duh! The compiler don't care but people reading your run on sentences do care.

I rarely see the closing } brace commented with the function (method for you 'modern' people) or control statement name to help in readability and matching up control flow braces. And just as rare comments above the function / class telling what's going on. There are tools if this is done right that practically create finished documentation for you if you do comment code (West Racing is a good example - you know he didn't sit down and write those docs afterwards).

 

I do like clean code (not necessarily lean code). I, too, hate UnityScript - the result is invariably messy and poorly organized.

 

That's entirely a matter of opinion, and starts religious wars. I find putting the { on a new line to be obnoxious and harder to read.

A few of my assets are JS, or at least contain JS scripts (e.g. Vectrosity and SpriteTile use JS for editor scripts), which are no more or less messy/organized than my C# code.

--Eric

 

Religious wars? Not hardly. Take a look at any grocery store receipt and know that newlines are your friend.

I find the auto-format utility of most editors works wonders for run-on sentences when I need to look at such code anyway. No religious wars needed.

 

"Lean" doesn't necessarily mean there's very little code, it just means there is very little useless/unnecessary code. Sort of like how lean isn't the same thing as skinny; you could weigh 300 pounds but if it's all solid muscle you'd still be lean. If you can write a complex algorithm in a few lines of code instead of hundreds, that's a good thing. And no, I don't mean just putting a hundred lines all on the same line.

For example, some coders like to copy/paste the same huge block of code ten times with slightly different variables names, when they should be turning that into a single function and calling it ten times instead. That is a prime example of unnecessary code.

 

The term "lean" is a lot like the word "simple". This was discussed in another thread, but basically simplicity can take on different forms:

1. Simple to write
2. Simple to use
3. Simple to configure

Unfortunately, these simplicities oppose each other and require tough tradeoffs. Want something simple to use? It's going to take you longer to write it then.

Ultimately, "simple" and "lean" just end up being marketing terms. And we all know marketing people are notorious for not discussing tradeoffs well.

People end up saying "lean" because they don't want to look like:

 

It's 100% opinion and not something you can force. Sorry. This is what I mean by religious wars--you will never convince me (because you're wrong), and I will never convince you (because you won't listen to reason).

--Eric

 

So, there's a few reasons you want your code as lean as possible. All are practical reasons:

1 - Lean code has less in it. This means, fewer opportunities for mistakes in the first place.
2 - Lean code is easier to debug (see the following points for why)
3 - Lean code can be easier to read, if written to be readable. This means, using proper whitespace, and commenting more arcane commands such that a complete newbie, or you in six months can read them.
4 - Lean code is easier to navigate. Again, there is less code to keep track of.

These are all considerations for when the developer is constructing the code at any time - whether it's initial development, maintenance, or refactoring.

 

This isn't a religious war. I'm just right and you're just wrong.

 

Silence, heathen! While I attempt to write "lean" code for the reasons Asvarduil mentions, I'd stop short of saying "as lean as possible". You can go too far and just end up with "cryptic" instead. For example, while I do use the ternary operator where it makes sense to me, I also deliberately avoid using it where it makes things confusing, even though it would result in shorter code.

--Eric

 

Less what in it? Be as specific as possible. An example would be good.

 

Lean code is simpler and easier to read, easier to fix, and less prone to conflicts. And usually more flexible too. The more hard-coded a system is, the less flexible it tends to be.

Of course as it was mentioned earlier, being too free-form with code can also cause it to lose focus. It requires a nice balance.

 

In marketing this buzz word will mean whatever the customer finds likeable whether it is that way or not.

 

So is lean code similar to kiss code? Because if something is kiss compliant then it should be very simple (lean) right? If not can someone explain the difference?

 

It doesn't mean anything. It's like "fresh" food, it has no real meaning whatsoever. When a grocer says "fresh" they mean it was picked/baked/butchered recently, or maybe that it hasn't been frozen, or perhaps that there's no preservatives. Who really knows? When Subways says "fresh" they mean something hasn't been toasted.

"Fresh" is just a vague, meaningless descriptive word that makes our brains think more highly of food. "Lean" is the same thing for code.

I don't generally trust what another coder says about their code or their design. I trust what I see of their work, or sometimes what others say about their work. The thing with code that gets shared is that the author's opinion matters far less than the user's opinion. Of course an author likes their own code, because they're familiat with it, they did it the way they thought best, and if they knew how to make it faster (within reason) then they would have done so - so unless they're advertising it as "a spaghetti wad of hacks I stacked up last weekend" then of course they think it's lean, efficient, well engineered and easy to understand. If they thought anything else then they'd have done it differently in the first place!

That goes for things I've written too, by the way. From time to time I've thought something I was doing was great while I was doing it, then came back some time later and thought "what in God's name was I thinking?" Thankfully it's a learning experience, briefly becoming your own customer and seeing what sucks about the experience, so as long as you're willing to accept that you're not perfect and to learn from your own mistakes it's actually a really useful experience, and you won't make the same mistakes twice.

 

They wouldn't use terms like agile to describe operating by the seat of your pants and such and still keep relabeling old methodologies with new hip acronyms to obscure what's really doing if a lot of this wasn't cliquish and exclusionary more than technical.

 

While I'll not disagree that it's often used to excuse bad practices or disorganized development, "agile" does have a specific meaning. "Lean" does not.

 

There is one area where lean code does make sense, and that's Javascript, since the JS has to be delivered in raw text format to your browsers so the "leaner" the better (takes the page less time to load). I suppose eventually this might actually matter when Unity 5 comes out, but that's a ways away

There's a few principles I've come across recently. One of my favorites is the One Responsibility Principle - your class shouldn't really be responsible for more than one thing. Another one is Inversion of Control - if your class depends on functionality of another class, make that functionality as abstract as possible (abstract base classes or interfaces where possible).
These two in tandem may not produce lean code at all (they're not designed to), but they often do produce good code.

Remember, lean code is not necessarily good code. Even if there's less of it there, it can still be a chore to decipher.

 

I know these aren't strictly good or bad but some aesthetics really perturb me and I just have to change them when I see them.

Code (csharp):

1.  
2. void Start() {
3. }

Makes me go crazy - I just have to do this every time:

Code (csharp):

1.  
2. void Start()
3. {
4. }
5.  

Ahhhh...fixed. Much better Feng shui.

Also if it was up to me I'd make use of preceding underscore illegal:

Code (csharp):

1.  
2. private int _member; // grrrr
3. private int my_member; // actually I like even though technically against MS guidelines
4. private int Member; // grrrr
5. private int member; // I like
6.  

 

This.

Take a look at the OPPOSITE of lean code or lean design.

MICROSOFT.

Everything they do is convoluted and bloated with useless features which simply destroy its usability and functionality. SO MUCH SO, one of their programs will actually destroy the usability and functionality of OTHER PROGRAMS.

Want evidence? I'll just throw out a random bug for Microsoft Office - EXCEL.

Your printer having a certain setting, will crash Excel if you change the Font or Font options (Size, Bold, Italics, Color).

How idiotic is that? Beyond idiotic. It verges on insanity.
To fix the bug, you have to change your default printer. Not a real solution, but the only working one. All to allow you to change Font Settings for your text. Durrrr...

Another example, just yesterday I tried installing a Mind-Mapping software. It froze at 0% installing, for over 10 minutes. Obviously this was an issue. I open up Task Manager, and what do I see? WORD.exe is open for some reason. I immediately knew the problem. If Microsoft Word was open, and my installer for some other program is frozen, then it's Microsoft's horrendous idiocy. And guess what? "Close Task" and boom! 0% to 100% instantly.
I've installed this program before, and never had this problem. Microsoft probably made a windows update to screw it up.



Computers used to be super pathetic compared to now. Yet as much as our hardware has advanced, our software hasn't really advanced at the same rate. I mean, when it comes to speed. I don't remember how long it took to start older computers with Windows 95, or how long it took for Internet Explorer to finish loading...but even if a computer is insanely fast comparatively, if it's a cheapo processor- it will be slower than a "fast" computer of the 90's. It's pathetic. That is because Microsoft, with every new version, bloats their O/S more and more. It's never-ending bloat.

There is a reason people depise Microsoft products (Internet Explorer compared to FireFox/Chrome.), Microsoft Software compared to "Light" or "Lean" free software which does the same things without the useless features. Linux not running five hundred processes in the background- 99% which you will never use, but if you turn even ONE off, it will ruin your system and force a format.

Bloat. Bloat. Bloat.

"Lean Code" sounds amazing. Only the features we need, and nothing more? Wow, that sounds awesome. It's so rare. It's so uncommon. Bloat is so horrendous.

"Lean Code" + "Source" sounds amazing. Easy to read and understand. The less code, the less to read, the less to get confused about, the less to contemplate and translate to your understanding, the easier to understand, the faster to comply with your requirements.

 

"Lean code has less in it."

"Lean code has less code in it."

If you take Code, and make it less, what is it "Less" of? Code.

But with less code, you also get less of everything related to code.

Less Code = Less Complexity = Less Confusion = Less Reading = Less Thinking = Less Fixing = Less Chance of Messing Up a Function = Less Processing = Less.

Less is Less.


An example of Lean Code would be this:


Code

Code (csharp):

1.  
2. import java.util.Iterator;
3. ...
4. for (Iterator<Integer> iter = list.iterator(); iter.hasNext();)
5. {
6.     sum += iter.next();
7. }
8.  

Lean Code (The Same Thing, but there is less code.)

Code (csharp):

1.  
2. for (int x : list)
3.     sum += x;
4.  

You are not importing "java.util.Iterator;" so there is less of a chance that will cause problems or result in errors.
You are calling fewer functions, which means less problems arise.
It is just...less...

 

Lean Code is just some kind of buzzword. As the term has no precise meaning, it is just pointless to discuss it.
Everyone who tries to give it a meaning by saying that certain coding guidelines should be followed to get lean code is pretty naive, as the quality of coding guideline in general is very subjective. Fewer is better is just another empty expression. Of course the code should be made as simple and maintainable as possible, but that has nothing to do with the shortest possible amount of code lines.

@CarterG81, less code doesn't mean less problems. Your snippet is in fact a potential source for trouble. Any language that allows to leave braces away for blocks with a single line statement will cause trouble for certain beginners. If you are in the scripting section on a regular basis, you'll see many beginners struggling if they try to extend what you call "Lean Code", just because they don't know that braces need to be place if there is more than one line within e.g. an if statement.
Trying to make that kind of absolute statement just doesn't work in my opinion.

 

Well one mans "less" is another mans "confusing". At least for me, when I see stuff like:

Code (csharp):

1.  
2. public static bool CanYouReadThisWell () { if (SomethingFitsOnOneLine) { WorkOutThatBottomScrollBar((float) AllDayLong); } return false }

I instantly change it to be:

Code (csharp):

1.  
2. public static bool CanYouReadThisWell()
3. {
4.     if(SomethingFitsOnOneLine)
5.     {
6.         WorkOutThatBottomScrollBar((float) AllDayLong);
7.     }
8.     return false;
9. }

Because it drives me up a freakin wall! - I mean what in the world compels you to NEED to fit all that code down in one funky line? There is no right way I guess but not a day goes by I work on code in any other format.

 

LOL, I've only seen this popularity of _ leading off variable names recently in Unity games. It seems to be a C# or gaming thing but for me it _ to begin a variable name are reserved for the systems programmers at a low level. And the business about capital letters has been throw out for a loop. LOL, these variant practices only evolved so students can disguise their copied code. I've even seen PD source in the asset store and the seller of the code said you can't modify the PD code, fail.

I'd never heard the term lean to describe code before Unity and these forums. I did write a com serial device driver in the 90's and was told that it would case trouble because my driver was too 'fat' however in truth that wound up being HW design flaws in the chip and unshielded com cables. So I guess lean code is fast code and elegant code, elegant meaning if you're told they are an infinite number of equations with the solution ' f(x) = 1' you choose the most elegant equation to represent '1'; that is simply '1 = 1'. Sorry that one can't look artificially smart with such a representation.

 

I use these guidelines a lot in my code lately:

• Private variables and methods always start lowercase.
• Likewise, public variables and methods always start uppercase
• Public comes before private
• Variables come before methods
• Stick code in regions by category (public/private/property/function)
• If it's public, document it via triple slash
• If it causes a compiler warning, fix it ASAP

I'm also starting to make use of the following principles I learned about recently:

• One Responsibility Principle - a class should have exactly one job. If the description of the class says "and" anywhere, time for a refactor.
• Open Closed Principle - a class should be open for extension, but closed for modification. I should be able to extend a class, I shouldn't have to muck about the code to do what I want.
• Linkov Substitution Principle - a subclass should do *at least* as much as the parent class, never less than the parent class (shouldn't remove functionality)
• Dependancy Inversion Principle - if this code depends on functionality provided by another class, make that interaction as abstract as possible (interfaces are best, followed by abstract classes, followed by concrete base classes) so I can change implementation without having to worry nearly as much about breaking thing.

 

Yeah, for the most part I agree, but like I said, if I see an asset advertise that it has "lean code" or any similar thing like "clean code" or "well-organized code", it means the author at least knows that code quality is important and has put in some amount of effort to make it legible. Or that the author knows that there are similar assets to theirs where the code is so awful that they know that readable code is a valid selling point.

 

I've heard lean used as a business term before that wasn't explicitly referring to coding. First time I heard it, it sounded more like if you weren't being "productive" enough (by our asinine measurements) you're ass is canned. Chances are it has been a term in someplace like IBM for twenty years, but it's only been heard of elsewhere for five.

Without looking on wikipedia, I'm almost positive lean code just means the features on the box are all that are in the package. It's more or less solving one problem with one solution, without a lot of extra variables in play.

As for what the people on the asset store mean by it, god only knows.

 

I think that's a bit silly to say lean code is bad because it can cause beginners to get into problems.

I assume lean code would be more of something desired by people who are experienced enough to read others' code and understand it correctly.
I'd imagine beginners should have bloated or inefficient code, because it's just easier that way.

When you aren't including additional source files, it has to help prevent problems solely for the fact you aren't important a ton of things which may conflict with something commonly included like System.

 

I think the point that's trying to be made here is that lean code doesn't mean anything. Lean code is not inherently bad code, but on the flip side lean code is also not inherently good code either.

 

Haha, true enough, being aware that "works" isn't the same as "finished" is a better start than some things seem to have.

 

No, it's really not.

Besides, everyone should always take the easiest path to reaching their objectives. (The key here is having smart objectives that don't then lead you to taking dodgy paths.)

 

1) There is no 'less' in that code, it's the same. 'Lean' code shouldn't have anything to do with new lines.

2) Even with your more readable version, you somehow missed that your code is always returning false (which smells bad).

I've helped plenty of beginners who've thought that. For example, beginners who don't understand arrays, assume they are complicated so end up with a monster of copy pasted if statements and variables that has subtle bugs and strange logical flow that is obviously not intended. Spend 5 mins showing them how arrays work, and suddenly they *love* them


------

IMO:

Lean is just a word people use to describe what they've attempted to achieve, and as such can mean different things to different people. However it does not mean 'compact' and certainly not 'compact to the point of being obfuscated'.

 

The top one IMO is far superior especial for a small screen.

 

Purely a matter of personal preference. However, "Egyptian" braces ( first brace on same line) drive me crazy.
Basically, my coding style is directly in line with Visual Studio's default formatting options. I suppose Microsoft agrees with me

 

I can attest to this, as my preference has changed more than once over the years.

That being said, my preference is to go with whatever is the norm in my current environment.

 

I don't think its preference more just what fits with your tools, I work on a laptop so having it that way lets me have a fair bit more code on my screen at a time.

 

You can always use region to collapse parts of your code , smaller fonts size...if you dont write 2000 line in one script scroll around should not be an issue either ..I also work on laptop and I prefer the block , easier to read for me , and this is just personal preference.

So i guess all that is like cooking and spice you prefer put on it ^^.

anyway when i have to collaborate with a team which use some specific guideline regarding code formatting or naming etc ..I just follow them , even if this doesn't fit the way I do usually ...

 

Just quoting for the sheer good looking code this dude does.


But on topic, I the definition of lean code to me means code that does the job with a great sense of logic and with a smart algorithm.

There's a lot of ways to skin a cat and some of them frankly grotesque, so lean code to me would be stripped of fat, and do a perfect job without useless bits on it. It's not about size to me, but being just as big as it needs to be in terms of algorithm used.

 

Yes I know, I was elaborating on a post a couple above, and the types of annoyances I see in others code. No functionality intended, just as an example of bad formatting for one line use.

 

That is contradictory. You disagree with me that beginners have newbie ways of handling code (bloating it up and making very inefficient code), claim it is NOT easier that way (If it were not easier for them, they wouldn't do it the harder way), and then say everyone should ALWAYS take the easiest path to reaching objectives.

All of this is bad advice.

First, beginners are beginners. What is easy for them isn't what is easiest for a professional. If someone is ignorant of knowledge, it is not easiest for them to take the 'easiest path'. It is easiest for them to take their limited knowledge and choose for themselves what is easiest. If bloated, inefficient code and tons of if statements are easier for them, it is irrelevant if for YOU or a more experienced coder that it is easier to wrap it all up in a single line or array. Understanding or Learning something you do not know can certainly be more difficult than using what you already know works. "The easiest path" is not the easiest path for EVERYONE. Especially when people think differently.

Second, you should certainly not ALWAYS take the easiest/laziest path to reaching an objective. Sometimes the harder, more difficult path, is the one which results in less bugs.

One should OFTEN use their experience to decide what path to take. They should not "ALWAYS" do anything.

Laziness can create Efficiency, but sometimes laziness can create bugs or idiocy. Saying ALWAYS when it comes to programming is just plain silly.
People, especially beginners, should try to take the easiest path to reach their objective so they get it done. That is true to an extent, because the most difficult thing is completing a project.

That doesn't mean it is the best path. Not in a long shot.

Imagine if NASA and the mathematicians and programmers handling the spaceship and launch protocols took "the easiest path". But wait. You said ALWAYS. Exactly. If that doesn't apply to video games, then what about simulation games? The only thing you should ALWAYS do is NEVER say ALWAYS.