⚠️ Warning: This is a draft ⚠️

This means it might contain formatting issues, incorrect code, conceptual problems, or other severe issues.

If you want to help to improve and eventually enable this page, please fork RosettaGit's repository and open a merge request on GitHub.

==worse programming pratices?==

In regards to the REXX version 3 example (yuppers, that was mine), has anybody ever thought of entering a Rosetta Code task:

  • what NOT to do
  • bad programming practices
  • real bad programming practices
  • don't-do-this-at-home programming practices, ... ever! Hurrumph! Hurrumph! -- [[User:Gerard Schildberger|Gerard Schildberger]] 20:29, 4 July 2012 (UTC)

: We've never gone in for documenting or promoting bad practices in the past. Sometimes it is necessary to use a somewhat-less-than-great practice to achieve a task, but whenever I've written such a thing, I've almost always also added a note to say that the example is non-idiomatic and would usually say what to use instead, which often fails to satisfy the task for technical reasons (e.g., “I'd use the built-in sort instead of writing a bubblesort implementation” in a task to write a bubblesort). I prefer to show how to do things well, and idiomatically too, instead of collecting ways to do them badly. –[[User:Dkf|Donal Fellows]] 08:13, 5 July 2012 (UTC)

:: I hope it was understood that I never suggested that bad practices are to be promoted, but rather exposed. More often than we care to admit, programmers use a "trick" or somesuch for golf-playing, brevity, space saving, or other reasons (even if good intentions was the primary goal), and whereas it may seem to be a good idea to the coder, it may be defeating the purpose in the long term. This is especially true, I should think, for Rosetta Code, where the programming examples are supposed to show how to solve a task (hopefully with clarity, logic, and good practices), but of course, my religion is better than your religion (this's stated to show that quite often, it's what's believed to be true/better, and not backed up with facts). Programming books have chapters (or at the least, disclaimers) on what not to do or shouldn't be done (as far as one method or style versus another). Some styles or methods are highly controversal, but when shown side-by-side with a better method, light can be shown on the merits of one versus the other. It's pretty hard to convince people that their code is hard or difficult to read, since the author of said code can easily read it (as it conceived/written by them), but other persons may have a much more difficult time perusing unfamilar code, or worse yet, an unfamiliar language. PS: your mileage may vary. For recreational use only. Void where prohibited. Not intended for small children. Restaurant package, not for resale. Other restrictions may apply. Do not write below this line. -- [[User:Gerard Schildberger|Gerard Schildberger]] 12:56, 5 July 2012 (UTC)