14
$\begingroup$

Do automatic style hints (like those provided by linters) significantly increase the student's understanding of the language they're learning? I am asking because I assist in a course that uses a language that is not widely used. A linter does not exist yet, and I'm wondering whether it would be worth the effort to make one.

Also, does it matter whether the style hints are provided as you type rather than upon saving or compiling the program?

I would love to see quantified studies about this, but personal experience is very welcome too.

Some things I am thinking about for a functional language (examples use Haskell) are listed below, but these are not vital for answering this question. Experience with other paradigms is appreciated as well!

  • When parentheses are(n't) needed. A common faux pas is to surround every application of a constructor with parentheses ((Just 5)), even when they are not needed, because it is necessary in pattern matches.

  • Writing int instead of Int, making a type variable instead of a concrete type.

  • Using where clauses for helper functions.

  • Suggesting pattern matches where guards where used (i.e., not checking | x == 5 but using a pattern match where x is replaced by 5.

  • Recursion that may not terminate. For instance, students tend to get confused writing functions that get no parameters, and end up writing things like instance minBound ... where minBound = minBound. (Not really a style hint)

Improve this question
$\endgroup$
6
  • $\begingroup$ I never knew what these kinds of systems were called before. Nice! Is it hard to make one? $\endgroup$
    – Ben I. ♦
    May 23, 2017 at 18:26
  • $\begingroup$ @Choirbean it depends on the kind of language and the kind of checks that you want to run. For imperative language, there are many tools that can do analysis like the number of branching points per function, line length, whether variable names conform to some standard, etc. If you want to check for things like loose coupling between components, component balancing, etc. or even suggesting different ways of writing the same, it gets more tricky. I am working with a functional language, and at first sight I would expect that the rules of thumb are harder to quantify in that paradigm. $\endgroup$
    – user24
    May 23, 2017 at 18:30
  • $\begingroup$ I can understand a little bit of pushing towards style, but how much would you want? Should braces go on the same line as an if, or the line below? Should they be indented, or not? Seems like a lot of this would come down to the instructor. $\endgroup$
    – Ryan Nutt
    May 23, 2017 at 18:42
  • 1
    $\begingroup$ @RyanNutt that is true, but some things are general ideas about code quality (I updated the question with some examples). Using locally defined functions, avoiding redundant parentheses and things like this are quite universal - and, the idea behind this question is that using too many parentheses (e.g.) may indicate a problem with your understanding of the language. $\endgroup$
    – user24
    May 23, 2017 at 18:44
  • 1
    $\begingroup$ Teaching advice: Feed back should be frequent and as soon as possible. From my programming experience (before I was teaching): Some people did not learn, until the feedback was given in the editor, as the code was typed. For getting buy-in for lint, we had to explain the difference between error messages, and errors, and that lint is your friend. Your role is not to minimise error messages, but to read them and allow it to help you minimise errors. Warnings help with potential errors, and latent errors (a latent error is one that may manifest, when someone changes the code). $\endgroup$
    – ctrl-alt-delor
    May 28, 2017 at 12:07

3 Answers 3

Reset to default
10
$\begingroup$

In my experience, immediate feedback is helpful in speeding along development, but rarely enhances understanding. In fact, I am often frustrated with the immense level of help that is provided to my strugglers, because they wind up moving words around until whatever they've written stops being underlined.

The only exception to this has been for norms that don't cause errors, such as using CAPS for static final variables in Java. In those instances, it is very helpful to have some sort of indicator that what they've done isn't perfect.

Edit: Now that I've seen your edit with examples, it seems like what you are contemplating is basically all of the stuff that I feel is helpful. In which case, I believe that it could be very helpful!

Improve this answer
$\endgroup$
4
  • $\begingroup$ So you've invented design by validation - but is it worse than before? Would they still struggle - if so there is a risk of mis-juding the value of the tool. $\endgroup$
    – Sean Houlihane
    May 23, 2017 at 18:42
  • $\begingroup$ It's a fair question, and I (obviously) only have a subjective answer. With my lowest performers, I believe that it is worse, because what helps them is to (slightly) increase the pain of the editing/compiling/running cycle. If it takes them 9-12 quick, thoughtless edits to get rid of a red underline in Eclipse, forcing them to compile after each one also makes actually thinking about what they're written comparatively more appealing. $\endgroup$
    – Ben I. ♦
    May 23, 2017 at 18:49
  • $\begingroup$ I'm cynically less interested in the lowest performers, more those who have latent talent (or talent in a related area that CS might unlock if they're not put off early). - but I appreciate that's not a universal approach... $\endgroup$
    – Sean Houlihane
    May 23, 2017 at 19:57
  • $\begingroup$ I work hard to pull my low-performers up, but the environment that I'm in absolutely forces me to. For you, I guess I would then say that for medium and high performers, other than the exception I've outlined above, that there's no substantive benefit. Convenience, sure, but they won't be learning more in your class for having a linter. $\endgroup$
    – Ben I. ♦
    May 23, 2017 at 20:03
3
$\begingroup$

This reminds me very much of a similar discussion from the distant past.

The Meat

Human perception is colored by expectations. Transposed letters, misspellings, and wrong punctuation are all easy for a human reader to miss because our perception is geared to fill in for the unexpected. We are all aware of these internet memes that build on the understanding that any misspelled word is readable provided it starts and ends with the correct letter, and has all of the other letters that are required somewhere in the middle, regardless of order.

Real time syntax highlighting and linting helps to expose those errors when they can be easily resolved, when the programmer is still thinking about the problem at hand. By preventing extra effort and distraction, it is a direct aid to understanding.

Compile time linting is better than nothing, but I remember spending hours poring over lint print outs for C programs (yep - C, not C++, not even ANSI C) for hours, making one edit, then rerunning the lint to find the next error. It was better than nothing, but not by much.

At one point in time. applications were written in a single language (COBOL, FORTRAN, PASCAL, etc). In a project of any scale today, you will use at least three programming languages (Example: SQL, Java, and Javascript).

The programming language is a tool, not an end in and of itself. Each language expresses specific thought patterns more effectively than the others. In industry, it is not uncommon for me to pick up a language just enough to accomplish a particular task and never work with it again.

Anything that reduces the time I need to spend learning the language is a benefit to me. Conversely, any language that I spend enough time in, I will learn in some depth.

I would expect the same to apply to students, since in this field we are always students.

The Long Stories - read at your own risk

I think it was the 1980's (or early 1990's), the same question was asked about the use of debuggers. Conventional wisdom was that the debugger would interfere with the reasoning process and students would not learn the material. A few rebels in academia held that in industry solving the problem faster was what was paying the bills, so debuggers should be used in classes just like in industry.

Ultimately, since this was a discussion in academic circles, someone (hey it's been a few decades, sorry no citation) did a controlled study where an entry level CS class was taught by a professor, half the lab classes were required to use the debugger, and half were required to NOT use the debugger.

Much to everyone's surprise, not only did the use of the debugger not impede student grasp of the material, it actually gave them deeper insights into what the system was doing when they ran code.

Fast forward three decades or so, there is a reason that we use syntax highlighting.

I learned programming on teletype and monochrome terminals, and I'm usually oblivious to color, so when I ran into an issue where my syntax highlighting didn't work I figured "no problem, I'm olde schoole" and went to work. It took me about 2 minutes to realize that without the syntax highlighting, the code that was nicely formatted to the language manual was nearly unreadable.

If I, having learned before syntax highlighting was an option and with decades of continuous industry experience, have trouble reading code without syntax highlighting, I pity the poor novice.

Improve this answer
$\endgroup$
0
$\begingroup$

This answer based on what I found as a professional programmers. What helped me to become a better programmer.

Immediate feedback

I found that immediate feed back helped, a lot.

  • full auto indent: not just indent the same as line above (I have seen this called auto indent, it is not). It must do it for you, it must get it correct all of the time.
  • text colouring.
  • bracket closing, including </blabla> or equivalent. It must get it right, and it must skip over the close bracket if I type it.
  • auto newline: I type : (python) or { (C languages), and it adds a newline character (and indents).
  • reversible backspace: when I press backspace it undoes exactly one key stroke, including all of the auto stuff (I have worked with editors where I spent more time undoing auto stuff, from occasional typos, than it saved me when I got it right).

Linters

This had a mixed effect within the team.

The better programmers, read the feedback, and changed the way they programmed for the better. In the short term there programmes improved because they reacted to the feedback. In the long term, them stopped making the mistakes.

However for some of the programmers, they found clever ways to get the linter to be quiet, but did not address the underlying issue that the linter was trying to warn them about. To tackle this issue, I gave permission to everyone in the team, to use the lint comment to temporarily disable a warning or informational, without having to ask any one. This way the problem was not hidden. We could then grep (a file search tool) for the lint comments, and review the code. If needed we would run group or one-to-one training sessions on what the lint warning was trying to say (what the risk was).

Most programmers understood the errors, as there is no ambiguity. But for warning, it is just saying “Warning doing it like that can lead to errors.”. This allows the ego to say, “But I know what I am doing.”. Sometimes we do, but mostly Lint was correct.

Some people see the [error] message as the error, so try to eliminate the message. There needs to be training on error/warning messages.

My experience tutoring a student in Java Eclipse.

A lot of the feedback given by eclipse is counter productive. The student reacts to the errors, without thinking. Just moving stuff about, and forgetting what they are trying to do.

The feedback is getting in the way of Test Driven Development: Only write code to make a test pass. To do this you have to write code that uses functions, procedures and variables that don't yet exist. The IDE tries to help, but it can't. It will sometimes change what is typed, and the student then seems to think that is what they intended to type.

(When I was learning to drive the instructor would say turn left at the next junction. When I got to a junction I would check to see if I was signalling in that direction, if so I would make the turn. All I could remember what turn at next junction, but not which way. If the car had auto-corrected me, I would have gone the wrong way.)

Some of the help that it give is useful. However if your work-flow differs from that of the IDE designers, then it is more of a hindrance than a help.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.