Why do asset makers advertise "lean code"?

, I wish I had time to care about such trivialities. My rules for coding:

Make sure others on the team can read it, no bugs, does what it says on the tin.

If some of the assets on the store could stick to these three simple guidelines it would make life much easier.

 

PhobicGunner, that's exactly what I wanted to say.

 

^ This.

Did you know lean beef can only contain 10% fat? A lean-to shares a wall with another building. A lean business might focus on a Minimally Viable Product.

TLDR; Lean is limited fat, walls, or features. And it applies to code.

Gigi

 

What is the fat, though? What does it mean to trim the fat out of code?
Does it mean getting rid of code that doesn't need to be there (which doesn't make any sense to advertise - "Look, I got rid of old useless cruft!" is hardly a selling point)
Or does it mean optimizing code? In which case "lean runtime" is probably a better term than "lean code".

 

It's not contradictory at all. You're operating on the false assumption that "bloated and inefficient" is easier. It's not easier, it's just quicker to make your first things happen that way. The only people who think it's "easier" are people who stop learning at that point.

You're also operating under the assumption that I think the same path is the easiest path for everyone. I don't .

The thing is, we're using the word "easier" to mean different things. I'm talking about "easier" in the context of "shipping a product with the least overall cost and effort". You're using "easier" to mean "faster to get something happening the first time" or something like that (I'm not sure exactly), and indefinitely continuing along those lines without ever learning more actually makes it far harder to get things finished to an acceptable level for shipping.

As for this...

... and various other things in your rant, the bit that you selectively removed from the quote already addresses that.

Less bugs? My objectives cover that. Taking experience levels into account? That's covered too.

Pick smart, meaningful, useful objectives, then figure out how you can reach them with the least time, effort and cost. That, to me, is "the easiest path".

 

Trim out the other guy's code!

 

...this is an impossible argument, I I will no longer participate after this post, which is primarily for others reading. You obviously are here just to argue, not to actually make any reasonable sense.

Anyone else who reads this can simply ask another human being if it's "easier" for them to apply what they know to solve problems, or to learn complex things they do not know to do the exact same thing. Any subject will do, doesn't even have to be about programming. You know... because "it is easier" is entirely determined by that person's definition of easy, their current level of ignorance, and their current level of knowledge.

I could rephrase that to "...because it is quicker to do what you know than to learn what you don't know." but that wouldn't be correct when asking them if it's easier.

Seeing as how my argument is primarily that it is easier for a newbie programmer to do things the way they know how than to sift the endlessness of the internet for what is ultimately an infinite number of ways to do things differently, I'd say that is a reasonable argument. My definition of "easier" being the simple fact that there is nearly an infinite number of ways to program, and it is often "quicker" (your words) to do how you know to do it than to read about people arguing about what is the "best way" or sifting through hundreds of tutorials to find what you call the "quickest way". All the while having to be careful because of how easy it is to go astray by taking bad advice which floods the internet alongside the good advice.

My argument includes that it is easier for YOU, but that doesn't mean it is easier for NEWBIES. Even if you are a newbie, it doesn't mean other newbies see the same way or know the same things. It is like trying to tell someone else what their opinion is. Once again, this is a valid argument as it is common for people to have narrow vision due to the limitation of their own perspective. This is a common human condition, where they fail to understand how something can be different for someone else because they either dont know or dont remember what it was like to lack certain information.

You however can feel free to argue over semantics all you want. "Easier" vs "Quicker" the differences, similarities, whatever. You could also continue to argue over the opinions OTHER people have (particularly newbies) and disagree with them when they say what is or isn't easier for THEM. You tell em man!

Enjoy!

 

My post seems to have sparked an outright war of opinions

 

"Lean" code could mean a variety of things. A lot of people seem to see it the same way I view code as "elegant".

I consider elegant code to have little to do with exactly where you put your braces and how you capitalize your variables, and more to do with the simplicity of the code, its readability, and most importantly what route it takes to accomplish its desired outcome. Consider this code:

Code (csharp):

1.  
2. public class CrappyBitOfCode {
3. private bool testThisBool = true;
4.      
5. public void Update() {
6. private bool isTheBoolTrue = testThisBool;
7. if (isTheBoolTrue == false) { Debug.Log("omg the bool is false"); isTheBoolTrue = true; }
8. else isTheBoolTrue = true;
9. if (isTheBoolTrue == testThisBool) { Debug.Log("Um. Bool."); }
10. }
11.  

It looks pretty ridiculous, but I've seen a million examples of code that works in redundant, silly ways. Not to mention that the formatting, while perfectly valid, is very hard to read. So the elegant version would be:

Code (csharp):

1.  
2. public class CrappyBitOfCode {
3.      private bool testThisBool = true;
4.      
5.      public void Update()
6.      {
7.           if (!isTheBoolTrue)
8.           {
9.                Debug.Log("omg the bool is false");
10.                isTheBoolTrue = true;
11.           }
12.           else
13.                isTheBoolTrue = false;
14.           Debug.Log("Um. Bool.");
15.      }
16. }
17.  

So we just did the same thing with less code that is more readable both due to formatting and syntax, although, for those obsessed with the pure AMOUNT of lines, we've definitely increased that. Pure amount of lines is a silly benchmark, since whitespace doesn't compile.

The part I can't show by example is that good code is split up into a variety of methods and classes to handle different bits. It is much easier to modify code that is properly split up, rather than one giant file containing all the code in one class and method. This is why object oriented programming exists. If you've ever had to type few thousand lines out of a magazine into a BASIC interpreter only to find that there's a bug, and you had to scour through those thousands of lines of code to find it, you would be ecstatic to split your code up into classes and methods. You would rejoice every time you had to go through 20 lines of code rather than 2000 to figure out what's going on with your bug. You would dance with pure joy after discovering that your bug was easily recognizable because your whitespace was properly formatted and the code read like a book.

ESPECIALLY beginners should learn to write their code using methods and classes to split the functionality up, and avoid extraneous code, because it's a key skill for being a professional programmer, or even a decent programmer. Beginner doesn't mean it's extra okay to be messy and throw your code all over the place, this makes it hard to read, hard to debug, hard to update, hard to fix, hard to replace. Good code should tell its story without you needing to scroll all over the place. Bad code will make even a good programmer bang his head against his keyboard as he spends hours attempting to figure out what it's supposed to do. Just do it right from the first, even if you're a beginner, and you'll save yourself a lot of time and headaches.

 

Or:

Code (csharp):

1.  
2. public class CrappyBitOfCode {
3.   private bool testThisBool = true;
4.  
5.   public void Update()
6.   {
7.     Debug.Log((isTheBoolTrue)?"Um. Bool.":"omg the bool is false");
8.     isTheBoolTrue = !isTheBoolTrue;
9.   }
10. }
11.  

 

Just goes to show that code can always be done differently, or more simply, or just plain better. Although really, "Um. Bool." wasn't inside the else bit, so the functionality is different. You just assumed the code made some sort of sense

Arguing about how exactly code should be done is silly, folks, since it's highly individual, as zombiegorilla has shown with his elegant use of boolean logic. However, encouraging beginners to do messy, ugly code is doing them a disservice.

 

Well, all I can suggest is that you read it again. Especially the part where I define what I mean by "easy".

I also suggest that you think through complete project life cycles, or at least full iterations. You currently seem to be thinking no further than the next task at hand.

I've seen people take the initially "quicker" approach countless times and end up bitten on the bum in a huge way because of it, such that reaching the end of the project actually ends up taking significantly longer as a result. If quick fixes that don't address real-world issues are your idea of "easy" then all I can say is that you're probably in for a lot more work than you expect.

Anyway, I've discussed this in length elsewhere (with real world examples), anyone interested in reading on the matter should be able to find it.

 

There's been many a time when I've not thought out my code, and just taken the quickest way, and wound up with code that I essentially had to rewrite from scratch because it was far too messy to effectively edit.

If you (general you) don't think writing nice, pretty code is worthwhile, write yourself a big long block of code that has badly named variables, has no comments, has a bad layout, takes weird, non-object oriented approaches, and is all just in one method. Then look at that code again in a couple of months and try to figure out just what the hell you were doing.

Have fun with that. Use lots of arrays. Maybe define each element in your many arrays individually. Use 5 dimensional arrays, why not, you can store a whole bunch of variables in one variable (also known as a class, but they're so complicated, let's just use an array). Use the same block of code 20 times, what's the point of a method call? Just make every variable public. Have a thousand public arrays constantly in memory. Line breaks? Who needs 'em. Put your entire script on just one single line.

Also, make sure everything is in Update(), so you do everything every single frame.