Do you *know* what you are coding?

eightohnine

This is kind of meta discussion about coding, but no matter if you're new to programming or a blackbelt code ninja, I'd be curious to have your thoughts on this:

I was wondering the other day if other people actually do fully understand every line of code they're writing? Or do they just repeat "patterns" they've seen somewhere and as long as the code does what it's intended to do, then knowing the finer ins-and-outs doesn't really matter so much? (I speak of patterns not in the software design sense, but rather just several specific commands or lines of code in a specific order.)

To give an example, I for a long time didn't understand the "void" in a function declaration. Even reading explanations about it made zero sense. But I knew that if I write "void" in front of the function declaration, then my program will work, so I never really bothered to know why I'm writing it down. It was only after I had to return something from a function for the first time that I got to know about return types and thus also the utility of "void".

Another example, if I use a double for()-loop to set up a grid, I to this day remain confused about which for() is responsible for vertical and which for horizontal placement. In the end I easily manage to draw the grid, but I'm never 100% sure I get that code block. (No need to explain it here. I know how it essentially works, I just need to focus when thinking about it and don't have it ingrained subconsciously).

And yet another example, for the longest time I didn't know that in Object-Oriented Programming "functions" are called "methods". And I would ask questions here in the forum and use "function" when I meant "method", which likely created some confusion. They look and behave the same, so no need to know the difference, right?

I've been dabbling in and out of Processing and other programming languages for many years now (as a hobby) and I'm absolutely capable to come up with and create more or less complex programs. But the continuing existence of these "not-quite-sure-what-they-really-do"-patches of code and syntax just make me wonder how much other people know about their code.

I'd expect that many full-time devs and coders would probably want to slap me for such a laissez-faire approach to programming. But is this so? Do pros know everything about their code? Or do they just have the experience to have a huge resource of patterns they can lean back on, without understanding every single one of them? On the other side, are programming beginners scared off by the seeming necessity to understand everything they write down?

Curious on anyones input.

Thanks!

TfGuy44

slap

eightohnine

Ha, yeah, I kinda did set that one up. :)

blindfish

@eightohnine: this is a good (and reasonable) question. I think a good programmer should strive to fully understand what they're writing; but in practice there's so much to learn you can't possibly know it all.

You should definitely understand fundamental concepts (and nested loops would fall into that category (just experiment and print the output of each loop until you get it!)); but should you know the full details of implementing visual or audio output? I don't think so. That's why we use libraries and frameworks like Processing. They provide abstractions so you can get what you want done without knowing the full implementation; in the same way a programming language is itself an abstraction that avoids you having to write in machine code.

I've definitely copy-pasted code and used it in production (in front end web development) without fully understanding it in the first instance: time constraints mean you sometimes don't get beyond a quick sanity check for obvious defects. If it's come from a reputable source and in testing it works reliably; why not? But when things settle down and you have time on your hands it's a really good idea to review and research such code so you do fully understand it; both as a learning process and also for quality control.

Do pros know everything about their code? Or do they just have the experience to have a huge resource of patterns they can lean back on, without understanding every single one of them?

Do you know absolutely everything there is to know about the spoken language you use every day (e.g. formal grammatical rules)? I doubt it. But do you have a huge resource of patterns you can lean back on and which you do understand? Absolutely...

plux

I think it depends on how you approach to coding..I did by studying computer science at uni, which is a really different approac of studying interaction design (for instance). Your examples (for loops, methods and functions, void) they can be solved by studying properly, step by step, with a computer coding book..obviously they might be less clear if you started by copying and pasting random things trying to 'sort it out'..other than that, I don't know exactly about the allocations of variables and all these much more 'hardware' things that happens when you compile your code, but I definitely know where I want to do when I'm writing code..and when I go crazy, I just come to this forum :D

eightohnine

@blindfish: I really like your last paragraph. It serves as a nice example on how to look at this issue.

@plux: True, the approach would make a big difference. I'm a designer not trained in comp sci, who just stumbled over Processing many years ago and thought the possibilities where great. So it was (and still is) very much a patching together of different knowledge fragments into working sketches. Today I know the basic commands Processing offers, but I definitely don't know proper programming patterns.

KevinWorkman

I think everybody feels that way to a certain extent. The only thing that changes is where you place the "line" between "stuff I know" and "stuff I just use".

For example, I'm relatively experienced with Java and Processing. I pretty much understand what every line of code is doing. However, could I tell you whether the window that comes up is a JFrame, a Frame, or a JavaFX window? Not without looking through the code or adding some print statements! The fact is that I almost never need to know what kind of window it is.

That line moves with experience, but I doubt anybody ever gets to a point where they understand everything about their code. Even though I know Java pretty well, I'm still pretty fuzzy when it comes to the internal workings of Spring, so I'm probably a lot like you when I use it- I use the functions without really knowing how they work.

And this is a good thing! This is the whole point of using a "high level" language like Java or Processing- so we can abstract away stuff we don't really need to care about! This is one of the great things about object oriented programming.

So I wouldn't worry too much about it. Just keep programming, and you'll become more familiar with stuff as you go (it sounds like that's already happening). But no matter how much you know, there will always be more that you don't know. And that's part of what makes programming so fun.

plux

@eightohnine I think that if you just get a programming book (whatever language you are more confortable with) you could easily fill the small gaps that you mentioned.. ;) I was talking with some collegues of mine which are designers and they are doing a 10 hrs workshop in processing..it's really cool for them and I think this is a really nice way to get in touch with things like processing but, the difference between something like this and a more 'scientific' approach is that by doing a real programming course you learn how to think, while doing a workshop can teach you the language itself and show some constructs but you won't probably fully understand what's happening..this is because a programming book will give you exercises that are focused on logic by usign the knowledge provided..this changes your mind..and when you start writing bigger stuff (a game with many levels and many variables to take care of, for example), that really helps..another very simple example..I still remember the first time I saw 2 nested for loops to deal with multidimensional arrays..I was like crying because I couldn't follow anything that was going on..then, that's where a good book comes in, with proper exercises made to train your brain in this kind of stuff :)

akenaton

@eighttohnine===reading your question my first idea was "that is a good question" then "but it s quite a philosophical one", then "because it s more general than about coding" then "e.g= when i speak???,or when i solve a math problem using some formula..."; and i was very happy to see that blindfish has got the same point of view... Going ahead= when i speak i dont think to all syntax or grammar rules, i only use them and am happy because it works: other people understand what i mean...Yet in some cases i can and must study these rules. When??? - When it does not work or when i am not trying to attempt some precise goal. As for me that is the same when coding: if i work for a client and have 3 weeks left before sending the code i dont take care of the meaning of all the code i am writing/using till everything goes well when hitting "enter". That not the same when i am "playing" without a precise goal, like an exercise. But what is true for me is perhaps not true for others: some men (or women!) want to learn in a very systematic way, other prefer trying by themselves and getting lessons from experience. What is true for all of them and for coding is that you never know all the rules and sub sub rules which are implicated into what you do, think or do...

koogs

those last two answers make me question if people know what they are writing 8) (paragraphs anyone?)

i would say 'yes' to the original question, at least at the statement level. but after a point things get complicated enough that you can't guarantee that what you're writing will do what you want straight off and it may contain mistakes. which is why we have debugging...

for instance, i couldn't write the code to draw a hexagonal grid perfectly the first time, but give me 20 minutes...

akenaton

@ koogs=== "people" does not know exactly what they are writing!!!

quark

I would also say yes to the original question in that I fully understand the Java syntax of every program I have written, but I don't always understand the code logic.

For instance in this discussion I posted code to draw the largest ellipse that can be inscribed into a convex quadrilateral. I fully understand the syntax of the code inside the calcLargestInscribedEllipse method but I don't fully understand how the algorithm (math) works.

Another example is the G4P library. I started writing that soon after I discovered Processing and although I understood the Java syntax of my program, I made logical errors because I lacked of understanding of how Processing works under the hood. I know a lot more now. :)

Knowing the language syntax is just a very small part of being a proficient programmer. Understanding the language semantics (e.g. object orientation), ability to develop algorithms, debugging, using common programming conventions and techniques ... etc are also essential skills to develop.

I'll stop there, I think 5 paragraphs are enough ;)

KevinWorkman

Also, with regard to the function vs method comparison: I wonder if that distinction is really a leftover from C and C++ developers?

You could argue that a Java static function is one thing, or that Processing functions are another, but it never really matters. I still don't know which is which without looking it up, and I've been a programmer for over a decade.

_vk

As an obsessive non-programmer hobbyist, I aways try to really understand what I'm writing. The most I can. And I feel that sometimes this leads me to re-invent the wheel, and never really finish anything, trying to understand and do it my self... I guess that if I would not go trough this path I might have accomplished more than I did.

But as said, I'm not a pro so this (not accomplishing) does not really matters to me...

eightohnine

Great input all around!

I believe Processing is an especially varied melting pot of different levels of knowledge and code comprehension, since it's mainly set up to be a language targeted at non-programmers. The way it simplifies syntax, hides overhead and generally focusses on visual programming output, are all aimed at people far from the computer sciences, who would otherwise be scared off by the initial opaqueness a programming. The community is inclusive to the whole "non-programming to comp-sci" spectrum making it so much more interesting to everyone.

quark

Functions and Methods

1) Subroutine this was a commonly used term in BASIC when every line had a line number and you would call the subroutine like this GOSUB 2600. Subroutines did not support parameters so all variables were global.

2) Function / Procedure used in procedural (non OO) languages to describe a block of code that could be executed by name. If I remember correctly Pascal had both functions and procedures. I think the difference was that functions returned a value and procedures didn't, but I am not sure. These supported parameters.

3) Method This is same a function in that it has a name, supports parameters and can return a value but it is used in object orientated languages. Certainly when I started to learn OO, suddenly functions became a methods, especially in OO theory.

In practice the names function and method get used interchangeably.

eightohnine

In practice the names function and method get used interchangeably.

That's what I thought too. Until I went to StackOverflow and got shit for using "function" when it was supposed to be "method" (according to the StackOverflow elitists).

eightohnine

@_vk: > obsessive non-programmer hobbyist

This pretty much describes me. I stumbled across Processing by pure chance, shortly after it had launched (and I think still was in alpha) and have been hooked since. This does make it 10+ years I've done programming, so one might expect I'd be a pro by now. And there where stretches (month, even years) where I didn't do any coding. Since programming to me never was a means to earn my income but rather just for fun side-projects, I never needed to know the absolute ins and outs. So yeah, today I might know how to whip up simple to complex sketches, write code using OOP, link up to Arduino and Kinect, etc., but I would not call myself a programmer in the same sense as if I had a full education in comp-sci.

GoToLoop

In practice the names function and method get used interchangeably.

• Each language got its own specific terms like: subroutine, procedure, method.
• But function is currently the de facto general term to describe all of them.
• That is, every method is a function, but not all functions are methods.
• Likewise, every field/property is a variable, but not all variables are fields/properties.
• A method is bound to an object and acts upon its fields'/properties' state.
• And it is also encapsulated within a class or comes inherited from another 1.
• Languages like C++, D, Python, JS, etc. got both functions & methods.
• Only when functions are bound to a particular object they're called methods.
• In Java since all functions are encapsulated within some class, theoretically pure functions don't exist.
• But that's just a matter of perception and how they're actually used.
• For example, java.lang.Math class is 100% static final & its constructor is private.
• We can't instantiate nor subclass it. Thus it can't have objects. Therefore it can't have state either.
• Since its methods aren't bound to any particular object, they're effectively pure utility functions.
• Now let's take a look at Processing's API. More precisely its processing.core.PApplet class.
• When we use Processing's IDE (PDE), the fact that ".pde" sketches are merged and wrapped up as 1 class which extends PApplet is hidden from us.
• Since our sketches is a subclass of PApplet, we can directly access its members w/o using the . access operator.
• Actually if we insist we can, by prefixing everything w/ this.. ;;)
• The other point is that in most cases only 1 instance exists. Acts similar to singleton classes iMO.
• If everything is just 1 object and 1 state, and we can access everything w/o .,
  wouldn't be so wrong to simply call PApplet's methods as functions? :-\"

shawnlau

I don't. Right now I'm working on a class that extends PImage - called ExPImage. It has many more filters like anisotropic diffusion, Contrast-limited adaptive histogram equalization (still working on that one- but real close), segmentation, bilateral filters etc. But I don't know math symbols, I didn't take calculus, and remember little about quadratic equations. Whenever you search for anything to do with image processing, the first thing the jumps up is the math symbols that look like hieroglyphics to me ( I call it math porn).

What I have to do is find code that does what I want to do and adapt it to what I'm doing. Most of the time, I can get it to work but I don't understand the mathematics of WHY its working. Take standard deviation. Seeing it enough times in code and algorithms, I could recite it by heart and recognize it when it comes up in code. But I have no idea why it works. The way I think of variance is subtracting a mean filtered image ( blurry) from the source.

I wish more sites would explain whats going on before jumping into the math porn.