flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Heap > Testing practices and the question of modularity


How do you test your code?
Manual
50%
 50%  [ 2 ]
Unit tests
0%
 0%  [ 0 ]
Test-driven development
25%
 25%  [ 1 ]
Behavior-driven development
25%
 25%  [ 1 ]
Something else
0%
 0%  [ 0 ]
Total Votes : 4

Author
Thread Post new topic Reply to topic
nyrtzi



Joined: 08 Jul 2006
Posts: 187
Location: Off the scale in the third direction
Testing practices and the question of modularity
I'm just rambling on again here vomiting half-baked ideas. I hope no one minds.

I'm still working on my way of doing things. I'm trying to get to proper behavior-driven style and then to make it routine because I think that doing so will help me keep the quality of my code better.

How do you guys and gals do it yourselves?

One thing I've run into is that when asked practically everyone talks of how they try to write modular code. I'm however wondering if that's mainly just lip service without much reality behind it.

The first step after all is defining what "modular" even means. I nowadays mainly think that the borders between modules are drawn according to the interfaces that break the dependencies between module implementations. Or perhaps it would be better to speak of different kinds or levels of modularity. Or to flip the question around and talk of the counterpart of modularity i.e. coupling. For example a subclass is tightly coupled with its superclass because of how it hardcodes the name of the superclass in its definition.

With interfaces regardless of if we are talking about how they're implemented as language features or if we just mean something that works like an interface we still get to flip the dependency around in the sense of for example module A depending on module B getting replaced by both depending upon the interface of B which allows one to rewrite B without causing any changes to A as long as the new B behaves the same outwards.

So should I just take a codebase and map out the dependencies between its parts and label as seams those parts that don't depend upon any other part? I could then divide the codebase according to those seams into modules in order to both count how many of them there are and to see what their sizes are.

If the code is not modular then the coupling and dependencies will make it harder to test. After all if things depend upon each other then firing up a part of the code will require that you fire up all the dependencies as well.

But if you wrote the code in a test-first or test-and-implement-simultaneously kind of way then there is practically no way that you can end up with code that is structured in a way that you can't initialize it in parts and test them independently of others in small chunks. And to me that sounds like code that just has to be more modular.

And then you still get the usual benefits of automated tests if you wrote the tests properly. In other words you don't need skip doing tests just because you're short on time as it's just a matter of running the test suite compared to the amount of work possibly needed if you did all of it manually. The tests help you stabilize the codebase at the seams between the modules and even inside the modules if you've implemented tests for that stuff as well. But then again I guess everyone here knows about how this is all about investing time beforehand into automated tests so that you can keep on moving faster later on because the tests will guard your back.

Maybe I'm still a bit brainwashed as far as this stuff is concerned but it all makes me feel more productive in perhaps a very feels over facts kind of way.

With code formatting I've already moved onto having formatting tools automatically figure out the indentation, etc. for me. Should I also start looking for each of my programming environments a tool that scans the codebases and calculates the modularity for me at the same time it shows me where the biggest problems are quality.wise? If there are none that I can use then is it worth it to write one myself?
Post 26 Aug 2017, 17:54
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6518
Location: Kraków, Poland
In case of my development of fasmg, I guess it could be said that it was a test-driven development. During the language design phase (before I started any implementation at all) I had prepared several snippets that needed to assemble in a certain way. Then during the implementation I have been adding them as tests every time I was readying another feature required to get them running. I had a slowly growing file with such snippet tests and I was using it during implementation to make sure that the tests that passed in the earlier builds still worked just as well as the new features were added. Even with modular code there still may be enough overlap between various parts that adding a new feature may interfere with something that was working before.

However, these tests were fairly simple and they were only really detecting if a change was breaking something really terribly. Later in development, I started relying more on an actual sources - example programs with complex macro packages - for the automated tests. This is something I have been doing with fasm 1 since its early days - I just build all the example programs I have before I put out a new version, to make sure that at least they are not broken by any new changes.
Post 26 Aug 2017, 18:37
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15096
Location: The Unicomplex
It depends upon your environment.

If your environment dictates rapid coding and fixes, then you've probably got no chance to get modules and unit testing implemented. And if you try to do it "secretly" you find that your boss yells at you for wasting time.

Otherwise if your environment allows for forward planning, and also allocate the time needed, then modules and unit testing are a really good way to proceed IMO.

As to how it is implemented that would be specific to the task at hand. The larger the project the more layers you'll probably need to help everyone understand the underlying structure. For smaller projects a flat layout might be prudent. And for tiny projects a simple tester procedure might be all that is needed. But whatever layout you choose, a bit of forward planning can definitely same time later on; especially when you need to come back a few months later and make changes.
Post 26 Aug 2017, 18:41
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 759
Mix of Manual and Test-driven -- like Tomasz I use short snippets for testing (e.g. compiler plugins). However, as other stuff is things like DSP and transformations, I test it manually. So that's what I voted. If it's wrong the result will be visibly wrong (or audibly), not much of a case of crashes and whatnot.

Unlike most people, I picture most coding paths while I code in my head. I try to even visualize any "cases" unless it's overly complex (and if so I use assertions to make sure in debug builds). I don't use assertions in asm code though (don't even know if that's possible without impacting release code) but asm functions are more about heavy computations than "control flow bugs".

I guess it also helps that I code in a very "clean" way in terms of programming practice -- not much of the bullshit you see from low-quality programmers giving "advice". In fact, sometimes I make the code design in a way just because it is beautiful and expandable (even if I won't expand it ever), even if it doesn't serve much practical purpose (other than not having idiotic side effects when changing something unrelated).

Thus, unlike most people who feel cool "revamping" their code every so often, I tend to just leave it be since it's already quite beautiful in design. Wink I hate "revamps", it's why so many bugs happen. If it ain't broken, don't fix it.


BTW when I say most people, I refer to those on stackoverflow since I'm semi-active there. I'm seriously tired of so many bad advice on there, or maybe I just ran into the wrong questions and people.
Post 26 Aug 2017, 23:27
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 6835
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699

nyrtzi wrote:

because I think that doing so will help me keep the quality of my code better


what is good in term of code?

https://en.wikipedia.org/wiki/Modular_programming

Quote:
Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.



i am far from a programmer,
just my simple minded view,

the idea of code, is the symbols that we use, group to command something,

code syntax,
- must be clear, (less typing is better until it could causes confusion)
- must perform what intended,

best is
- code able to reuse

personally, i think, it should behaves like car, you could have zero knowledge regarding car's internal, but you could still drive that car,
Post 27 Aug 2017, 04:33
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 187
Location: Off the scale in the third direction
Hmm, interesting. I'm reading from and between the lines that you guys have been doing the things I'm trying to learn. Which tells me that I'm going in the right direction.

On one hand testing that a specified input produces the expected output without tying the test into the details of how it is done which sounds like behavior-driven style that is a rational counter-reaction to the kind of test-driven people where tie the tests to the details of the implementation.

And on the other hand picking a testing approach that takes into account if automating tests is worth the effort as a part of the actual coding workflow.

The style I've been trying to strive towards is behavior-driven style that is judicious as far as what is worth automating goes. So no, I'm not going for the approach of blindly testing everything and writing all tests beforehand even if it usually makes sense to specify the desired outcome by incrementally growing the test first towards the expected outcome.

As far as the boss yelling at me goes it is true that I haven't asked for permission to go test-driven when I've done it. I haven't had that many chances yet but I'm working on it and working on the attitudes of the boss too.

There is one clear example that comes into mind though. I had to quickly come up with a client server solution with a protocol of its own that would act as a specification for others to do their stuff with. I had to write client library for a mobile platform too so I first made a prototype command line client and a similar server.

Writing the client and the server at the same time allowed me to constantly test each of them against the other. Once I had both it was easy to hand them over to the people responsible for writing the server for production use and for me to write the client library. After all I could constantly test the client library against the server prototype and be sure that I was going into the right direction without breaking anything that I already had got to work.

I just wish that the people writing the server had done the same and used the test client to guide what they were doing. I ended up having to modify all of my code in the end to make it compatible with the changes they made without even noticing they had made them. After all by not running the tests they had no clue they even had broken anything.

So yes, I feel like that episode kind of taught me a thing or two about the value of having automated tests in the right places i.e. that I can go faster and break a lot less of existing functionality if I have the right kind of tests in the right places covering my back. In the long run I can make a lot more progress that way. If it's something small then investing time in writing tests might not be worth it. That is after all one way of looking at it i.e. as an investment into more sustainable development pace.

I guess one thing to remember about all of the trendy and hyped buzzword driven development is that for example the practices that the consultants sell have a business behind them and are mostly advertising of what they want to get paid for by getting to teach about. What they say makes sense depending upon the kind of situation you're in but for example the fact that for some development practices you need a team that is already skilled and self-organizing is something they tend to forget to mention.

As far as revamping code goes doesn't that depend upon the level of rot of the code? To maintain its functionality any piece of code needs to adapt to the relevant changes in its environment. Even code that is perfectly good by itself might have to be rewritten if you no longer have access to anyone within your organization who can maintain it. Which is why I somewhat hate immature platforms like new trendy ones for Javascript and so on that change and break things often enough to feel like they're actively trying to pull out the rug from under your feet.


sleepsleep wrote:
what is good in term of code?



Whatever the equation is it centers around the ratio between the value it provides in relation to the resources required to produce and maintain it. I think everything else can be derived from that.


sleepsleep wrote:
code able to reuse



That's the thing isn't it. What is it that determines how reusable an arbitrary piece of code is? Isn't it once again the coupling i.e. dependencies or the lack thereof?

And what is the value of reuse? Isn't it being able to build upon previous work? Isn't the aim of automation and using computers that of better efficiency by making things easier?

But then again it is common that I run into people who speak of OOP implementation inheritance as the ultimate form of reuse but all I see is hardcoded dependency between the superclass and the subclass. I don't know why but I just have a hard time wrapping my head around that way of thinking.
Post 27 Aug 2017, 13:26
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6518
Location: Kraków, Poland
There is one more thing I may add about testing (slightly on a tangent, perhaps): I have found fuzzing very useful in my work on fasm and fasmg. I've been using afl for this purpose and it is really a good tool for finding problematic code paths that may have been missed by manually prepared tests.
Post 27 Aug 2017, 13:45
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15096
Location: The Unicomplex
The "if used ..." paradigm in fasm allows us to use common source code libraries in many different projects without including massive amounts of unused code blocks. This is one way of enabling code reuse. fasmarm natively supports a processor (and coprocessor) selection that allows a single common source code library to be used across different CPUs with different capabilities. Once the library is all tested and verified it can be used in many different places. But as usual the details matter and sometimes such niceties aren't possible depending upon the situation.
Post 27 Aug 2017, 13:56
View user's profile Send private message Visit poster's website Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 187
Location: Off the scale in the third direction

Furs wrote:

Unlike most people, I picture most coding paths while I code in my head. I try to even visualize any "cases" unless it's overly complex



I have a need to visualize as well which is why I quite often find myself drawing up conceptual models of different sorts to clarify to myself and others what the code or design is all about. Then again if I remember correctly psychologists and neuroscientists talk about how it is easier for humans in general to remember things by visualizing them maps and routes than as abstract lists of things. I usually feel a need to see in my head how the code is supposed to work even if the representation in my head is made out of high level concepts.


Furs wrote:

not much of the bullshit you see from low-quality programmers giving "advice"



Just wondering how you define and draw the line between low and high quality programmers. The low quality ones are the kind of people who don't actually even understand what they're saying nor are they striving to understand?

I get it that programming is not a science but I find it frustrating when people don't even try to apply the principles of scientific thinking into what they're doing with code.


Furs wrote:

In fact, sometimes I make the code design in a way just because it is beautiful and expandable (even if I won't expand it ever), even if it doesn't serve much practical purpose (other than not having idiotic side effects when changing something unrelated).



I don't know what beautiful is but I do get why you'd want to structure the code in a way which makes it less tangled and more robust even if you can't show that it will pay off right now.
Post 27 Aug 2017, 14:20
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 759

nyrtzi wrote:
Just wondering how you define and draw the line between low and high quality programmers. The low quality ones are the kind of people who don't actually even understand what they're saying nor are they striving to understand?

Exactly. In fact, those people purposefully tell someone to "just use X" and not even bother to learn how it works -- and by how I don't mean low level and every detail, but just a high level picture about it. Some of those even say "don't use raw pointers, use abstractions", boggles my mind. They are also the reason so much code is in such piss poor state, since they keep re-iterating the "don't bother with any optimizations until you really think you should optimize [whatever]". Now half of it is ok, I mean no point optimizing something that isn't even gonna work.

But most people end up writing code super fast without thinking about the consequences, then they realize it's designed like shit from the start (because they ignored all optimizations, even algorithm optimizations), and are too lazy to go and redesign it which would waste more time than making it properly from the start to begin with.

As a result, the code is left with shitty workarounds and gimmicks and is what I'd call "disgusting ugly code". Wink (yeah well beauty is subjective anyway)

It is because of people like that that C++ gets such a bad rep from people (like Linus). It's not a bad language, especially since it can almost be used exactly like C. It should be used like the name implies: a superset of C, or C with more features, NOT as a different language.

The fault is those idiots who say "use C++ like a new language, without almost any C construct" and teach this shit to people who will never understand pointers because they've been taught they are "bad". Same with gotos (rofl when people prefer having 500 bool variables and 500 ifs instead of a few goto).

Then they won't be able to debug the code, or even worse, they don't understand why a "stupid workaround" works and just leave it at that, leading to security exploits and other crap. Simply because they have no idea what they're doing -- they were taught by retards to ignore raw pointers, so they never learned them. Raw pointers are just an example, of course.

In fact, programming should be taught from bottom up, not top down. Basics first. That means the simple low level stuff first (simplistic CPU implementation, memory access and layout, etc), then the abstract stuff, but those people teach it the other way around. Which builds up on it.

I mean, I learned it that way and it was MUCH simpler to me (I started off with wrong foot since that's what retards teach). And it's not me having a problem understanding pointers or what a code is doing or why it crashes, they do. To me it's proof enough.



In summary, abstractions are good, if you know why you abstract it in the first place. You shouldn't abstract something for the sake of it and not even understanding why or what it's supposed to accomplish. That's just dumb.

Knowing how abstractions work (on a high level) also enable you to use them without sacrificing performance or having bloat, at all. Just need to know basics.
Post 27 Aug 2017, 15:24
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15096
Location: The Unicomplex

Furs wrote:
... people who will never understand pointers because they've been taught they are "bad". Same with gotos (rofl when people prefer having 500 bool variables and 500 ifs instead of a few goto).

Usually when someone tells me something is bad that makes me want to investigate it. Occasionally I come to the same conclusion about its badness, but often it is just someone hating it because they don't understand it, or it confuses them.
Post 27 Aug 2017, 21:08
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 759
Well no joke, some people bugged Linus on kernel mailing list for using "goto error" to handle the error case from the function. His alternative was this kind of shit:

Code:
failed = 0;
while(blah)
{
  for(foo)
  {
    if(something_fails)
    {
      failed = 1;
      break;
    }
  }
  if(failed)
    break;
}
if(failed)
  actual_error;

Instead of:

Code:
while(blah)
{
  for(foo)
  {
    if(something_fails)
      goto error;
  }
}
// ... success part ending with return

error:
  actual_error;

Seriously? It's disgusting, even from design point of view. What the fuck does it go through these people's heads? These people are brainwashed and I consider such programming teachers as propagandists. Seriously, can't explain it otherwise.

Linus, of course, used his "proper" language against his shit. He deserved it, anyway.
Post 27 Aug 2017, 22:50
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 187
Location: Off the scale in the third direction

Tomasz Grysztar wrote:

slightly on a tangent, perhaps



Isn't it more fun that way anyway? And thanks for bringing up fuzzing. Another thing I need to learn properly it seems.


Furs wrote:

nyrtzi wrote:
Just wondering how you define and draw the line between low and high quality programmers. The low quality ones are the kind of people who don't actually even understand what they're saying nor are they striving to understand?

Exactly. In fact, those people purposefully tell someone to "just use X" and not even bother to learn how it works -- and by how I don't mean low level and every detail, but just a high level picture about it.



Based on what I've seen too there are a lot of people who don't care about understanding why and how things work. A lot of people who program for work with the attitude "I don't care. I just work here."

However then there are the nerds who feel uneasy unless they understand what makes it all tick. Guys and gals similar to those people who take their electronic devices apart just so that they can see what kind of components they have eaten.

I don't consider myself a very good programmer. I feel like I know at least most of the basics but there is a whole lot of advanced stuff out there that I don't get. For example C++ template metaprogramming still largely looks like voodoo to me. I know programmers who suck a lot more than me so I don't consider myself hopeless. However my productivity is total crap compared to what I expect from myself. I'm happy with how I do when I'm "in the zone" but it seems so very hard to get there with all the distractions.

There is one thing I'm kind of worried and at the same time pissed off about. The level of programmers that come out from schools with programming related degrees nowadays. How do the educators expect the students to learn to write code properly if they don't need to learn the tools of the trade and are not made to write enough code to actually form any routines for it? What hope do companies have of being able to recruit them for something useful if these kids don't even know what recursion or a hash table means?

I swear that the next time I need to interview an applicant for a coder's position I'm just going to skip the FizzBuzzes and other tasks and tell them to bring their own code along for a review.

And I'm not very impressed either by how few of them seem capable of reading and understanding for example IETF RFCs and standards documents from IEEE and ITU. In addition their ability to look up information seems limited to looking stuff up from Stack Overflow and Google searches. Both googling and looking things up from SO are of course handy and important but to be limited to those only is kind of bad.


Furs wrote:

Some of those even say "don't use raw pointers, use abstractions", boggles my mind. They are also the reason so much code is in such piss poor state, since they keep re-iterating the "don't bother with any optimizations until you really think you should optimize [whatever]". Now half of it is ok, I mean no point optimizing something that isn't even gonna work.



Others add to that the rule that "Do not optimize until you're profiled your code so that you know you're optimizing the right thing." After all especially high level code might behave in unexpected ways due to how many layers of bloat there is between it and the raw hardware.


Furs wrote:

But most people end up writing code super fast without thinking about the consequences, then they realize it's designed like shit from the start (because they ignored all optimizations, even algorithm optimizations), and are too lazy to go and redesign it which would waste more time than making it properly from the start to begin with.

As a result, the code is left with shitty workarounds and gimmicks and is what I'd call "disgusting ugly code". Wink (yeah well beauty is subjective anyway)



Yep, the problem of not paying enough attention to quality leads to bad code. However there is one other problem here too. Many don't seem to bother to learn how to write well-structured code anyway and that combined with the fact that people can't write code more high level than their know-how leads to much of the code floating around being apprentice level code because that is the level of the writer after all. An apprentice can't do master level work. And combine this with how people normally don't write many comments and don't produce any documentation of any sort then the overall level of things will be annoying.


Furs wrote:

those idiots who say "use C++ like a new language, without almost any C construct"



Stroustroup, Meyers, Sutter et al are saying things like that too but. There is a big but there. For example references and smart pointers are nice and make it easier to write robust code but that doesn't mean that you don't need to learn pointers and understand the performance characteristics of all the things mentioned above. After all in many situations good old pointers are still the best tool for the job. For me the biggest annoyance with C++ is that the learning curve is steep and long. It feels like there is so much I'd need to fully understand before I could use it effectively that I sometimes wonder if it is worth the effort.

Then there is the dumbing down of the software industry. The industry needs more and more programmers so at least to me it seems inevitable that the level of talent will go down. And like I said I have very little trust in the education system to produce proper professionals.


Furs wrote:

In fact, programming should be taught from bottom up, not top down. Basics first. That means the simple low level stuff first (simplistic CPU implementation, memory access and layout, etc), then the abstract stuff, but those people teach it the other way around. Which builds up on it.

I mean, I learned it that way and it was MUCH simpler to me (I started off with wrong foot since that's what retards teach). And it's not me having a problem understanding pointers or what a code is doing or why it crashes, they do. To me it's proof enough.



No disagreement here. The higher level main concepts of programming itself are probably way easier to demonstrate if there is less bloat in the middle adding hidden complexity. The lack of bloat also allows for a closer look into the performance characteristics.


Furs wrote:

In summary, abstractions are good, if you know why you abstract it in the first place. You shouldn't abstract something for the sake of it and not even understanding why or what it's supposed to accomplish. That's just dumb.

Knowing how abstractions work (on a high level) also enable you to use them without sacrificing performance or having bloat, at all. Just need to know basics.



If one doesn't know how or why the abstraction works then how can one understand the performance and resource consumption implications? And if one doesn't understand that stuff then can one really even appreciate the value of the abstraction and know when it is proper to apply it?
Post 28 Aug 2017, 04:39
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 6835
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699

nyrtzi wrote:
I swear that the next time I need to interview an applicant for a coder's position I'm just going to skip the FizzBuzzes and other tasks and tell them to bring their own code along for a review.


i suggest you try the following,
1. give questions, hard one, out of programming fields, physics questions, maths etc, probably questions that you don't have answer either,

2. give them laptop and internet access, give them 2 hours, ask them to find solution,

3. review their solution by asking them to present their solution one to many,

personally, i think the ability to google, find solutions, is the most important skill set, Wink

btw, sorry for not replying your replies because your topic is actually very deep, and requires lots of deep pondering for me to output a meaningful sentences,
Post 28 Aug 2017, 04:55
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 187
Location: Off the scale in the third direction

Furs wrote:
Well no joke, some people bugged Linus on kernel mailing list for using "goto error" to handle the error case from the function. His alternative was this kind of shit:

(snip)

Seriously? It's disgusting, even from design point of view. What the fuck does it go through these people's heads? These people are brainwashed and I consider such programming teachers as propagandists. Seriously, can't explain it otherwise.

Linus, of course, used his "proper" language against his shit. He deserved it, anyway.



The problem I see with that structured approach is that the level of nesting doesn't tend to stay within reasonable limits. In other words it doesn't scale.

For example consider a function that needs to acquire exclusive access to 5 resources before it can do its real job. If one follows the structured approach of nesting conditionals and predicate variables how simple and readable will the code be considering that you'd be nesting not only the acquisition but also the releasing?

Even with the lessened locality due to the GOTOs I still usually find the code that uses GOTOs more readable simply because the structure is less convoluted. For example first you try to get the resources in order one by one, then you do the job and afterwards you release them in the reserve order. The setup, the actual job and the release are all laid out top to bottom without less need to rely on an IDE to make sense of where I'm going due to the nesting. And I don't need to worry about the extra variables either.

It isn't that uncommon to see people put code in the web with 5 levels of nesting. For me the limit is usually 3 if the indentation of the class or the function body don't count. If I have more than 3 I usually go back to the drawing board to simplify things.
Post 28 Aug 2017, 05:06
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 759
Well I wasn't arguing against gotos, I actually find them much better myself (as long as not overused, but that applies to everything). But people like that actively think that gotos are evil because that's what they were indoctrinated with.
Post 28 Aug 2017, 11:52
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 187
Location: Off the scale in the third direction

Furs wrote:
Well I wasn't arguing against gotos,



I know. I didn't say that you were. Unless I mistyped.


Furs wrote:
I actually find them much better myself (as long as not overused, but that applies to everything). But people like that actively think that gotos are evil because that's what they were indoctrinated with.



I agree. Some common structures in code are easier to express in a readable way using gotos. The same structures that the kernel developers use them for. It's them who helped me get over the last vestiges of my distaste for gotos even in high level code.

Indoctrinated? Yes, that is a good description.

I've heard many programmers say a certain thing about the field of programming. That it is more dominated by fads, hype, trends and fashion than it is by critical thinking and real professionalism. I think that's true. Thus my main concern now is how to form a more scientific approach to how I design and write my software. After all science tends to be pretty much the opposite of blind faith in the silver bullets that the snake oil salesmen sell.
Post 28 Aug 2017, 15:07
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.