A good example of a bad practice

1

Screenshot 2025-12-31 at 1.26.31 PM
Screenshot 2025-12-31 at 1.26.31 PM782×500 49.5 KB

Now some will say “Oh but Norm you’re being to computer sciencey” …
But passing parameters that control the behaviour like this should be avoided
Its a practice know and CONTROL COUPLING and for good software should be avoided

Tightly coupled systems tend to exhibit the following problems:

  1. A change in one module usually forces a ripple effect of changes in other modules.

  2. Assembly of modules might require more effort and/or time due to the increased inter-module dependency.

  3. A particular module might be harder to reuse and/or test because dependent modules must be included.

Never mind that to do something like left & right pad a string using this extension looks like


Var s As String = “1011”
s = s.Pad(“0”, False, 8).Pad(“9”, True, 12)
Break // s = “999910110000”

instead, this seems much more readable (although its not clear what 8 and 12 refer to - is it resulting length or # of patchers to add ?)


Var s1 As String = “1011”
s1 = s1.RightPad(“0”, 8).LeftPad(“9”, 12)
break

Both result in the same string

Something to think about when you design your methods & modules

2 Likes
2

Nobody will say that, you are only logical. Why making more effort with no effect except bad readability and having at the end a bad maintainable software? Believe me or not, this typ of programmer has no interest in it while he always can read his code

1 Like
3

I think it would be great to have these best practices tied in the documentation. Hobbyist programmers (like me) won’t usually know them just by using the language (and will often wonder “how is better” after having learn several ways).

4

TBH this would never make the documentation literally because Geoff considered this sort of thing too “computer sciencey”

5

When I saw the code I felt like something was wrong but didn’t care enough to figure it out. You’re spot on in the analysis.

The other thing that might make it more readable is using an enum for left/right that way it would be explicit rather than true/false. But again, then you’re back to the problem of what 8 and 12 refer to.

1 Like
6

Some of this is just ‘school of hard knocks’ sort of learning. You have to do it the wrong way and learn from your mistakes. And not that the code is bad, because it works, but long-term maintainability makes it less than ideal. And if you have other people working on your code it’s less than ideal too.

I made good money fixing other peoples mistakes as a Xojo consultant and some developers never learned. I fixed the same type of mistakes from another consultant that we even had an internal name for it. “Oh, this is XX code. Got it.” It was awful spaghetti code that was hacked together, overly complex, and easy to have edge cases that weren’t handled properly but were very hard to deconstruct. Often we just had to rewrite (which isn’t ideal).

1 Like