Is Jason's coding really spaghetti?

Mushroom · 2019-06-05 11:05:57

I belive Toxic said something like that in recent thread.

I have no experience in coding whatsoever, but I kida know how it works in general and why sometimes you can do something and why sometimes you can't. But I am curious if what Toxic said is true and why.

And if this really is a mess, can you repair it somehow? Or would it require to write the game from scratch?

Valareos · 2019-06-05 11:26:42

Depends on definition of "Spaghetti"

As a coder, when I hear spaghetti code, it usually means code without proper documentation, or layout. When you look at properly designed code, you see a lot of comments (like //Build database) and brackets lined up to where close brackets are vertically aligned to the line that opened that bracket.

Spaghetti code, then is code where it is very hard to see where one bit of code ends and another begins.

Jason's code is very well laid out, easy to follow, and certainly not what I would describe spaghetti code

Toxic · 2019-06-05 11:27:05

Mushroom wrote:

I belive Toxic said something like that in recent thread.
I have no experience in coding whatsoever, but I kida know how it works in general and why sometimes you can do something and why sometimes you can't. But I am curious if what Toxic said is true and why.
And if this really is a mess, can you repair it somehow? Or would it require to write the game from scratch?

Hey Mushroom, yes I did say that Jason’s coding is spaghetti and I thing a lot of people will agree with me. Now don’t take this as me saying Jason is a really bad programmer or game maker, but simply it’s how he finds it easy to code. He probably learnt C++ back when I was a little kid back then the language was most likely taught differently and written differently. It’s like a lot of things in life they change and become easier... bu if you learnt something 20 years ago and now there was an easier way to do it
you have 2 options.

1. Change your way and convert to using the new method.
2. Continue doing what works for you.

Now Jason’s coding in general is hard for a beginner to learn and understand. Even some people with coding experience like (Whatever) the guy who made the hetuw mod have trouble understanding some aspects. Jason writes code in a confusing and long manner which is simply not to easy to grasp unless your Jason himself. Now I’ve been learning C++ and had a lot of progress so far and a lot of Jason’s code now that I look at it can be written shorter and more effectively. Jason has years of experience in coding so I can’t judge but to me and a lot of other people the code is confusing and loooooooonggggg....

(Also the reason why there aren’t a lot of modded servers and just mods in general)
I hope this cleared some things up!

Toxic · 2019-06-05 11:30:59

Valareos wrote:

Depends on definition of "Spaghetti"
As a coder, when I hear spaghetti code, it usually means code without proper documentation, or layout. When you look at properly designed code, you see a lot of comments (like //Build database) and brackets lined up to where close brackets are vertically aligned to the line that opened that bracket.
Spaghetti code, then is code where it is very hard to see where one bit of code ends and another begins.
Jason's code is very well laid out, easy to follow, and certainly not what I would describe spaghetti code

Uhhhh ok man your Jason’s twin......

Valareos · 2019-06-05 11:33:14

Toxic wrote:

Uhhhh ok man your Jason’s twin......

I am also 40 years old I do have to look up the new fangled quick coding now and then myself lol. I understand fully in programming in what you know. its quicker, and optimizing as you go can be very very hard and distracting.

Valareos · 2019-06-05 11:38:18

But yea, normally term spaghetti code is not about syntax, or how easy/hard it is to follow the long programming, but the structure. Here is a example from a reddit page for spaghetti code to do 100 Beers on the wall. It works... BUT you can see there is a much better structure to use.

Toxic · 2019-06-05 12:08:55

Valareos wrote:

But yea, normally term spaghetti code is not about syntax, or how easy/hard it is to follow the long programming, but the structure. Here is a example from a reddit page for spaghetti code to do 100 Beers on the wall. It works... BUT you can see there is a much better structure to use.
https://i.redd.it/r9oh1m4ifu4x.png

Yeah lol that looks lols.

wondible · 2019-06-05 12:34:43

Jason tends to write long integrated functions. There are few arguments for this - efficiency (fewer function calls) and directness (if you want to know what it does, just start reading, no jumping to different functions). However while Jason has a big picture of what things do from writing it, it is very challenging for an outsider to understand the high level structure when that is not presented in a page or two of function calls. Due to the size of the functions I still find myself jumping around and cross referencing a fair bit to understand what the function's internal state is at that point. The degree of integration can also make things harder for us modders specifically - for instance the click handler does a lot of complicated context interpretation, and then formats action messages to the server inline. I pretty much re-implemented chunks of this for my keyboard actions.

lychee · 2019-06-05 13:09:08

I'm not really a C++ developer, so I can't really compare to the industry standard, but Jason tends to roll his own versions of everything from the lowest level rather than using libraries (I think he restricts himself to code that is nearly in the public domain). Consequently there's a level of complexity involved in reading his code -- and it takes a hefty amount of dedicated time to study his personal "minorGems" library.

It's great from an educational standpoint, but the barrier-of-entry is quite high for someone else to tackle Jason's code.

I wouldn't quite call it "spaghetti code" -- that's sort of a misnomer, and Jason's minorGems are very well documented. However as an analogy, whereas lots of programmers these days would buy a uniform pencil (standardized, 2B hardness) from Walmart to draw a picture, Jason makes his own pencil from scratch to draw a picture, which means Jason's pencil might not have the exact same behavior as everyone else's standard pencil.

Oddly enough, Jason has had so much experience making games that he's developed his own framework to developing games -- which impacts readability in its own way.

And to really understand Jason's code fully, you actually have to understand his entire framework -- which is a lot more complex than the typical indie developer's game.cpp main() function where everything lives.

Last edited by lychee (2019-06-05 13:10:07)

futurebird · 2019-06-05 13:16:31

I've always considered "spaghetti code" to mean using libraries way too much, using large complex libraries to do simple things. But, then I'm "old" too and learned to code before most of ya'll were born.

It kind of shocks me how much people use libraries now, or how people tolerate applications being HUGE when it really isn't needed. I think Jason't code is more on the clean side than a lot of what I see.

BladeWoods · 2019-06-05 17:57:58

I'm not a C++ developer either but know other programming languages, and Jason's code is definitely not spaghetti code, but what does strike me is the huge size of his files.

BerrypickerAF · 2019-06-05 18:33:11

Sounds like Jason 're-invents the wheel', which is one of the first things I was taught NOT to do in coding class over a decade ago after initial introduction to C++.
By coding everything from the ground up it's a lot more work for you and people likely will have a hard time understanding what you wrote (especially if it's not documented well). In the end it's all up to personal preference though, some people choosing to do so to protect their code from script kiddies, others because they learned it that way and never bothered to streamline their process.

Last edited by BerrypickerAF (2019-06-05 18:37:26)

jasonrohrer · 2019-06-05 18:51:19

The reality is that OHOL is 100,000 lines of code. There's no way to make that "simple and easy to understand" for a beginner. Yes, it could be structured in various ways, but there's no way to eliminate the fundamental complexity. Finally, the more that code is structured, the harder it can become to follow, because you have to jump all over the place (often into different files) to understand what is actually a linear set of operations.

I don't know if you've ever tried to read someone else's code that was heavily structured, or even worse, written "the right way" in C++ with lots of classes and templates.... it's a nightmare of indirection.

The primary rule is this:

Only write a function if you find yourself doing the exact same operation more than once. This is the "right" way to use functions, because they are helping you avoid code duplication, and avoiding duplication makes the code easier to maintain and reduces the occurrence of bugs.

If you write functions for other purposes, you are adding code complexity without any fundamental benefit.

The only time I cheat on this rule is for really complex algorithms that are hard for me to get my own head around, and then breaking the algorithm down into well-defined sub-problems helps me. The other case is where solving a one-time sub-problem is going to require a lot of local state, and you want to encapsulate those local variables to avoid polluting the variable namespace. But probably, in that case, a local bracket block is just as useful.

But the opposite is often just as likely true: in order to execute this one-time sub-operation, you NEED access to a lot of the local variables in the context where the operation is executing. Separating this sub-operation into a function will require that you encapsulate this state and pass it into the function call. This is messy, bug-prone, and adds a lot of code complexity.

The best example is the message-processing block in both the client and the server. There are cases in there for each type of message that might come in, and the code for processing each one is unique, and the code depends on a lot of local state. There's no reduction of code duplication to split these out into separate function calls (one for each message), and a lot of extra complexity for passing the state. So, it's probably best to just bite the bullet and write them there together linearly as separate cases, with no function calls. The result is a 9000-line monster, but so be it.

Spaghetti code is, by definition, code that has a lot of gotos and indirection all over the place. A long linear series of operations, all in one place, is not spaghetti code. Spaghetti code is hard to follow, because you have to jump all over the place to understand what it's doing. Linear code is not hard to follow. You walk through it in order. The complexity is right there, out in the open. The complexity might be overwhelming, but hiding it in a bunch of one-off function calls isn't going to help.

FINALLY: I use a very powerful text editor, Emacs, which has "search" as a fundamental atom. It's actually faster for me to jump to some spot in one file than to jump around between different files. A lot of more "modern" editors have some kind of search dialog box that is a real pain to use.

Spoonwood · 2019-06-05 19:05:24

BerrypickerAF wrote:

Sounds like Jason 're-invents the wheel', which is one of the first things I was taught NOT to do in coding class over a decade ago after initial introduction to C++.
By coding everything from the ground up it's a lot more work for you and people likely will have a hard time understanding what you wrote (especially if it's not documented well). In the end it's all up to personal preference though, some people choosing to do so to protect their code from script kiddies, others because they learned it that way and never bothered to streamline their process.

This sounds true to me also. It makes me wonder how efficient his code is, as even though one's code can be more efficient than some more standard way of doing something, assuming that your way of doing something is better than some library that *might* have gotten developed with efficiency in mind can be hazardous.

Whatever · 2019-06-05 19:15:15

jasonrohrer wrote:

If you write functions for other purposes, you are adding code complexity without any fundamental benefit.
The only time I cheat on this rule is for really complex algorithms that are hard for me to get my own head around, and then breaking the algorithm down into well-defined sub-problems helps me.

I dont understand this, you are saying that writing functions for other purposes adds complexity but at the same time you only do this when you have really complex algorithms? because you want to add complexity to the really complex algorithms?

lychee · 2019-06-05 19:38:14

I personally come from a test-driven-development world where unit testing is heavily emphasized, so there’s a greater tendency for us to break things up into modules that can be independently tested.

I actually feel really insecure when I don’t have test coverage on my applications haha XD

But I can understand the gist of what Jason is saying.

Whatever · 2019-06-05 19:40:06

I am not a good programmer, i know this, i often write silly code,
But i try to learn and improve, sometimes looking at other peoples code teaches me things.

If you (or anyone else) have time could you explain to me:

I saw you write closing brackets like this:

if ( true ) {
}

everywhere else i see it like this:

if ( true ) {
}

why?

i saw that you use a 1d array instead of a 2d array for mMap in livingLifePage.cpp, is this more efficient? would it not be easier to use a 2d array for this?

you create a new char array like this:

char *message = autoSprintf( "MAP %d %d#",sendX( mapPullCurrentX ),sendY( mapPullCurrentY ) );
delete [] message;

you could also do it like this:

char message[64];
sprintf( message, "MAP %d %d#",sendX( mapPullCurrentX ),sendY( mapPullCurrentY ) );

the second example has the advantage that it deletes message own its own when it goes out of scope, this avoids memory leaks.
there are atleast 2 issues on github that point to memory leaks caused by the first version.
Why is the first version better?
Why not use strings instead? they have many useful functions that makes dealing with char arrays easier.

Last edited by Whatever (2019-06-05 19:44:54)

Valareos · 2019-06-05 19:59:22

I have been known to create functions to make it easier to work on one section at a time in the code, then at the end, replace the function call with the actual function. Similar how you would build a complicated Excel formula. Get it workign in bits, then combine it all so it only takes up one cell

jasonrohrer · 2019-06-05 20:05:40

My bracket style is Ratliff style:

https://en.wikipedia.org/wiki/Indentati … liff_style

I learned it this way in some Intro to Programming class, and never looked back (or maybe I misunderstood the instructor, and made up my own style by accident). I feel like Ratliff looks cleaner, because the ending brace lines up with the content that it encloses, instead of "hanging" out in empty space to the left.

I use a 1D array because it's also possible to loop through all elements without resorting to a nested loop, AND because the allocation and deallocation is much simpler. A 2D array is actually an array of pointers to other arrays, so you need to allocate and deallocate in a loop.

w, h;
numTiles = w * h;
tileArray = new int[ numTiles ];

for( i=0; i<numTiles; i++ ) {
    tileArray[i] = 0;
    }
delete [] tileArray;

That code seems pretty simple and clean.

To do the same thing with a 2D array, it's much more complicated and bug-prone:

w, h;
tileArray = new *int[ h ];

for( y=0; y<h; y++ ) {
    tileArray[y] = new int[ w ];
    }

for( y=0; y<h; y++ ) {
    for( x=0; x<w; x++ ) {
        tileArray[y][x] = 0;
        }
    }

for( y=0; y<h; y++ ) {
    delete [] tileArray[y];
    }

delete [] tileArray;

Also, for the 1D version, you can memcpy the whole array very easily, etc. If you really want to access it as X and Y, then you still can like this:

for( y=0; y<h; y++ ) {
    for( x=0; x<w; x++ ) {
        tileArray[y * w + x] = 0;
        }
    }

So, you can have it both ways.

As for why not use statically-allocated arrays everywhere, that is dangerous unless you spend time thinking about how big the resulting printed string might be. Yeah, 64 is probably big enough, but you had to pick a number. Also, if you end up passing the string outside of the function, it will break, because it's on the stack of that function only. But using auto-allocation onto the heap, I never need to worry about the right buffer size, and I can use the same code to return a string or use it internally and free it. The trade-off is a memory leak potential, but I use leak checkers on my code anyway, so that's not a problem.

Whatever · 2019-06-05 20:16:08

Ok thanks for explaining it.

Valareos · 2019-06-05 20:27:22

I tend to use the Allman bracket style myself for code I make from scratch, but will default to style used in a program if i am modding or troubleshooting code

Grim_Arbiter · 2019-06-05 21:02:08

If by spaghetti you mean delicious, then yes.

I actually haven't gone through the coding for this game, but when i see examples of it in the github with changes, I can usually decipher what changed by reading the code. However I'm mainly a script kiddie and just change 0's to 1's and plug in stuff. I'm guessing by spaghetti you guys are saying its jumbled without some kind of natural order?

One Hour One Life Forums

#1 2019-06-05 11:05:57

Is Jason's coding really spaghetti?

#2 2019-06-05 11:26:42

Re: Is Jason's coding really spaghetti?

#3 2019-06-05 11:27:05

Re: Is Jason's coding really spaghetti?

#4 2019-06-05 11:30:59

Re: Is Jason's coding really spaghetti?

#5 2019-06-05 11:33:14

Re: Is Jason's coding really spaghetti?

#6 2019-06-05 11:38:18

Re: Is Jason's coding really spaghetti?

#7 2019-06-05 12:08:55

Re: Is Jason's coding really spaghetti?

#8 2019-06-05 12:34:43

Re: Is Jason's coding really spaghetti?

#9 2019-06-05 13:09:08

Re: Is Jason's coding really spaghetti?

#10 2019-06-05 13:16:31

Re: Is Jason's coding really spaghetti?

#11 2019-06-05 17:57:58

Re: Is Jason's coding really spaghetti?

#12 2019-06-05 18:33:11

Re: Is Jason's coding really spaghetti?

#13 2019-06-05 18:51:19

Re: Is Jason's coding really spaghetti?

#14 2019-06-05 19:05:24

Re: Is Jason's coding really spaghetti?

#15 2019-06-05 19:15:15

Re: Is Jason's coding really spaghetti?

#16 2019-06-05 19:38:14

Re: Is Jason's coding really spaghetti?

#17 2019-06-05 19:40:06

Re: Is Jason's coding really spaghetti?

#18 2019-06-05 19:59:22

Re: Is Jason's coding really spaghetti?

#19 2019-06-05 20:05:40

Re: Is Jason's coding really spaghetti?

#20 2019-06-05 20:16:08

Re: Is Jason's coding really spaghetti?

#21 2019-06-05 20:27:22

Re: Is Jason's coding really spaghetti?

#22 2019-06-05 21:02:08

Re: Is Jason's coding really spaghetti?

Board footer