# A good example of a bad practice

**URL:** <https://ifnotnil.com/t/a-good-example-of-a-bad-practice/4574>\
**Category:** Other\
**Created:** [31 December 2025 20:43 UTC](https://ifnotnil.com/t/a-good-example-of-a-bad-practice/4574 "2025-12-31T20:43:01Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\
**Post date:** [31 December 2025 20:43 UTC](https://ifnotnil.com/t/a-good-example-of-a-bad-practice/4574/1 "2025-12-31T20:43:01Z")

</div>

![Screenshot 2025-12-31 at 1.26.31 PM](https://ifnotnil.com/uploads/default/original/2X/6/606a571705ee20b3c52367cb2042c1602a168b72.png)

> **[Fill up a string with given char](https://forum.xojo.com/t/fill-up-a-string-with-given-char/87352/2)**
>
> Here’s an extension function that you can put in a module for left or right padding: Public Function Pad(extends input as String, padCharacter as String = "0", left as Boolean = True, toLength as Integer = 16) As String '// Example usage ' ...

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](https://en.wikipedia.org/wiki/Coupling_(computer_programming)#Types_of_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](https://en.wikipedia.org/wiki/Ripple_effect "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](https://en.wikipedia.org/wiki/Code_reuse "Code 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

```auto

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 ?)

```auto

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

---

<div class="post-metadata">

**Author:** ![thorstenstueker](https://ifnotnil.com/letter_avatar_proxy/v4/letter/t/aca169/32.png) [@thorstenstueker](https://ifnotnil.com/u/thorstenstueker)\
**Post date:** [31 December 2025 23:32 UTC](https://ifnotnil.com/t/a-good-example-of-a-bad-practice/4574/2 "2025-12-31T23:32:43Z")

</div>

> [@npalardy](#):
>
> e

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

---

<div class="post-metadata">

**Author:** ![anic297](https://ifnotnil.com/user_avatar/ifnotnil.com/anic297/32/18_2.png) [@anic297](https://ifnotnil.com/u/anic297)\
**Post date:** [1 January 2026 08:16 UTC](https://ifnotnil.com/t/a-good-example-of-a-bad-practice/4574/3 "2026-01-01T08:16:17Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\
**Post date:** [1 January 2026 11:33 UTC](https://ifnotnil.com/t/a-good-example-of-a-bad-practice/4574/4 "2026-01-01T11:33:49Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![bkeeney](https://ifnotnil.com/user_avatar/ifnotnil.com/bkeeney/32/225_2.png) [@bkeeney](https://ifnotnil.com/u/bkeeney)\
**Post date:** [5 January 2026 13:48 UTC](https://ifnotnil.com/t/a-good-example-of-a-bad-practice/4574/5 "2026-01-05T13:48:20Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bkeeney](https://ifnotnil.com/user_avatar/ifnotnil.com/bkeeney/32/225_2.png) [@bkeeney](https://ifnotnil.com/u/bkeeney)\
**Post date:** [5 January 2026 13:55 UTC](https://ifnotnil.com/t/a-good-example-of-a-bad-practice/4574/6 "2026-01-05T13:55:06Z")

</div>

> [@anic297](#):
>
> I think it would be great to have these best practices tied in the documentation.

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).