This is very much an open ended question and is meant to raise a discussion.
(Also, if you feel that any critique is aimed at you; it’s not. Some examples may be triggered by what some of you wrote, but it’s not meant to be judgmental. These are questions that have grown with me over years through interacting with this community and others throughout the internet. It’s just very applicable to the core idea behind Processing).
//
When trying to convey solutions and give support (to novice coders in particular) I’m never sure at what point it is right to introduce more rigid coding best practices and proper terminology.
Participating in various threads throughout the years I’ve observed that other contributors style, detail-level and preparedness to push best-practices does vary a lot. It becomes extra apparent if those contributor types converge on the same topic.
Personally, I often opt for a more “non-coding language” when giving an answer. For example, I’ll talk about “creating and filling an array” instead of using terms like declare and define. Both convey the same idea, but one is clearly more topically sound and correct, when viewed from a “best practices”-perspective.
In a recent post about fundamentals of arrays, one answer introduced the idea of static and final keywords for non-changeable data. And the follow-up discussion kinda took several steps away from the basic problem at hand.
Or, naming conventions. Wouldn’t a novice just need to know that “make the name descriptive”? Maybe know about camel case. But then introducing snake, screaming, prefix, Hungarian, etc. may be more of a distractor in the moment.
And a classic, someone is struggling to handle several items on screen, like declaring x1, y1, x2, x2, x3, y3, etc. The obvious answer is “Use OOP!”, but that is placing a coding Mt. Everest in front of someone who hasn’t yet gotten an intuition for navigating a cartesian coordinate system.
//
Just to drive home my point, I’m coming from a place where I believe that a majority of novice coders get thrown off already by the presence of “void” in a function declaration. Their brains are not yet wired to think in “return types”. In my mind – and based on my own experiences – the existence of “void” is not questioned, but instead it’s a pattern you have to follow, otherwise your code breaks.
This is obviously not bashing novice coders, on the contrary, I’m trying to be extra aware of how prepared or willing they are to take on replies and their ability to digest proper technicalities of programming therein. In my mind, wrapping answers into non-coding language can help take off the edge a little.
I then also believe that there is an upper limit of how detailed or in-depth an answer can be, before it begins to become an obstacle in and of itself.
//
I now hear some of you say, “That’s laughable, obviously anyone serious about using Processing will have the basics down and are open to learn more advanced terms, practices and conventions.”
One question to ask here is: What is the end-goal when supporting someone in this forum?
- have them duct-tape together a working sketch, best-practices be damned
- prime them for a CS career
The answer clearly is “it depends and always consider the context”. But I believe it’s vital to shape your answers appropriately, even if it means dumbing down and foregoing what you know would be better.
Despite Processing’s maturity and the many advanced topics discussed in this forum, I still feel that Processing has this distinct “for non-coders” urgency to it. Specifically, creatives and artists that want access to the possibilities of creative code BUT at the same time have little to no interest in becoming proficient coders. Just good-enough coders.
//
What is your take on this? What motivates you to write your answers the way you do? What do you put extra focus on? What do you deliberately leave out? Do you think in one-size-fits-all or do you shape an answer based on who is asking?
No rights and wrongs, all opinions welcome.