Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Reading and Writing and Programming
URL: Reading and Writing and Programming
At 8:00 AM on Mar 1, 2007, Matthew Schmidt wrote:
Fresh Jobs for Developers Post a job opportunity
So, how does the author suggest that we can fix this? Introduce more courses in debugging and maintaining code into the Computer Science curriculum. I think this is a great idea, and we would see the quality of applications in general go up if developers recognized the pain early on that a poorly written program causes. What do you guys think? Take a look at the article and share your thoughts here.
36 replies so far (
Post your own)
Re: Reading and Writing and Programming
It's a good idea. Better still ensure that the comments don't agree with the code because in practise this is what you find. Hopefully they'll learn to program using sensible names ("C" has a lot to answer for) and comment wisely.In development, if programming groups are separate then the support group should QA the build code - they're the guys that will have to understand it later, probably in a hurry.
Re: Reading and Writing and Programming
What a great blog that is!I agree with everything he says except I don't really see much code that looks "too encapsulated."
The point about college classes only teaching writing and not maintaining code is a great one. It's just incredibly disappointing that CS majors spend most of their time writing code rather than maintaining code.
I'd love to put together a college course called "real-world software development". I'd give the students an impossible deadline, vague requirements, and make them all work together from an existing code base. In the middle, I'd change the requirements, and add a few more requirements. I'd make sure they had to find and fix existing bugs as they worked. I'd have them switch responsibilities in the middle and have one or two people "leave the project" and one or two join.
In the end, I would have each student take over someone else's code, and the studen't grade would be based 30% on whether it worked or not, 30% on what the student taking over the code thought of the code quality, and 40% what I thought of the code quality. I bet you'd see more comments than code
Oh, and of course if you're not doing well or your fellow students don't like you, you may very well get kicked out of the class, perhaps with two weeks notice.
Re: Reading and Writing and Programming
public int test() { doSomethingElse(); int total = 0; for (int i = 0; i < m_array.length; i++) { if (process(m_array[i])) { total++; } else { total--; } } return total; }public int test() { int i, total; doSomethingElse(); total = 0; for (i = 0; i < m_array.length; i++) { if (process(m_array[i])) { total++; } else { total--; } } return total; }To me, code looks a lot easier to read with:
- braces on its own line, opening and closing braces aligned.
- declare local variables as late as possible, keeping it in an as local scope as possible.
- write member variables differently as local variables.
Be consistent. Write like this and everything looks fantastic. I'm repeatedly stunned at how people write code.
try { BufferedReader reader = new BufferedReader(new FileReader(file)); try { doStuffWithFile(file); } finally { reader.close(); } } catch (IOException ex) { System.out.println("Error writing to file " + file); }BufferedReader reader = null; try { BufferedReader reader = new BufferedReader(new FileReader(file)); } catch (IOException ex) { System.out.println("Error opening file " + file); return; } try { doStuffWithFile(file); } catch (IOException ex) { System.out.println("Error do stuff with file " + file); try { reader.close(); reader = null; } catch (IOException ex) { System.out.println("Error closing file " + file); } } if (reader != null) { try { reader.close(); reader = null; } catch (IOException ex) { System.out.println("Error closing file " + file); } }Oh my god, what the crap. But this is what I see over and over.
Re: Reading and Writing and Programming
That would indeed be an interesting experiment !!!This should in fact be a required exercise.
Re: Reading and Writing and Programming
Yes, that's true. Programmer must understand programs others wrote and be able to fix and maintain those programs. And yes, more training around code debugging must be done. I find that younger programmer tends to refuse maintenance project, which is a shame because there is so much to learn from other's code - no matter if it's good or bad.But that's not correct to put the fault on layered architecture alone. I think the author is wrong when he says:
"The consequence of this is programs with many layers where each layer might be relatively easy to understand but the entire program doesn't make much sense."
Because the entire program should not be looked at low level. Layered architecture help understand a program at high level, so you don't have to care about all those layers during maintenance.
Layered architecture are there to be able to make abstraction of layer not directly concerned by the work to be done (business logic do not need to take care of ORM... isn't it?). And that's where bad architecture fail... That make me think that bad architectures are worst than no architecture at all. And I think that that is another theme which must be better addressed in education of software engineers: architecture and design. And better yet, be able to distinguish good architecture from bad architecture.
Re: Reading and Writing and Programming
And what remote chance in Hell do you think that they would spend time on actually making legible, readable, and/or documented code?If there's any real time pressure, none of that will occur except through happenstance or any habits they may have already picked up.
Because the truth is that deadlines rarely wait for documentation unless documentation is part of the deadline. And in many cases, a working program is more valuable to the company (or the class in this case) than the documentation is.
Even when Team A inherits Team B's code, horrible as it may be, the basic fact is that Team A's changes will be against a subset of what Team B wrote. Of that subset, there may well be a few truly indecipherable bits. And when Team A hits those bits, they'll either simply decode it themselves after some more study, or they grab a Team B member to try and explain it to them.
And as soon as the code works, and passes their test, Team A and B are off racing to the next deadline.
People have been complaining about bad code since Day 1, and we'll be complaining about until Day N.
The only impact that can be made on this is if coders are trained from day one to right reasonable code. If the instructors make 30-40% of the grade based on code presentation and documentation. Then, readable code because mostly "habitual".
But, in the case of this exercise, if that habit isn't already embedded in to the students, it's already too late, and they'll fight through the problem like they would any other issue.
Bigger problem
I think the bigger problem is we write code. When we think about a piece of an application we want to write we just write. You can go to your masters degree and not do any design. That is write a paper on what are the requirements, what are the functional requirements, what are the use cases. Draft and create UML diagrams. I'd like to see an instructor say and this week's assignment I want you to turn in functional requirement for your application.Then take those papers for the following week and pass them to another student to implement. The week after implementation pass the program and requirements to another group to test the application.
Apparently this would be too complicated for college students, but this is the real world.
Re: Bigger problem
> Apparently this would be too complicated for college> students, but this is the real world.
Too complicated for students or for their instructors?
Java does not encourage readability
Java has inherited from C/C++ a gimmicky syntax that relies on lots of cryptic special symbols. It also has a number of omissions that make writing readable code unnecessarily hard. For example, the strictly enforced source code organization makes it hard to keep logically related code together. And the lack of keyword arguments makes complicated method invocations nearly unreadable. Without iteration syntax, type parameters, and auto-boxing, there were additional issues affecting readability, although many of those have fortunately been fixed by now.So, while students could surely benefit from more courses on debugging and maintaining, Java has always had, and continues to this day to have, serious problems with writing readable code. There are other languages that support writing readable code much better.
Re: Java does not encourage readability
"There are other languages that support writing readable code much better."Penny for your thoughts. What are these languages?
Re: Reading and Writing and Programming
I'm betting you see the latter style over and over because it's the java coding convention and it's the default formatting atleast in NetBeans:http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#449
In college, I followed the school's Java coding convention:
public int test() { doSomethingElse(); int total = 0; for (int i = 0; i < m_array.length; i++) { if (process(m_array[i])) { total++; } else { total--; } } return total; }I would still probably prefer this style if I could figure out how to configure NetBeans to use it. Most people I work with generally prefer putting braces on their own line, but unless they're using a simple text editor they generally use the IDE's defaults.
Re: Reading and Writing and Programming
I think there is a certain "I need to be clever" phase that any programmer goes through. When I was 16 I thought logic like was tremendously cool because you could pack so much logic into one line. It took a few instances of spending three hours trying to understand one line of my own code to cure me of this.A couple of years ago I participated in an interesting programming contest in Florianopolis, Brazil. You got an assignment and were divided into teams of 3-4 people. You had 15 minutes to architect what you were going to do. After that, you were not allowed to speak to each other. The first programmer goes and writes some code, and silently gives it to the next, who must understand the code the first programmer wrote by reading it, and so forth. It struck me as much more like the real world of software development than most academic exercises - it was really refreshing (of course, being the "Sun Guy" everyone wanted me on their team, and when I sat down to code it was on a Portuguese keyboard and I was paralyzed trying to find ; and { and was more of a liability than an advantage - but it was fun).
I mean, the real world of commercial programming is, here's this thing, you don't know how or why it works without reading it (sometimes with reading it), and you have to figure out what the person who wrote it was thinking enough that you can go fix things. And you know that if you rewrite it all, you'll leave an equally enigmatic mess for the next person. So, if you know you're probably going to leave an enigmatic mess anyway, the least you can do is try not to - which means clarity for the sake of clarity - at the expense of the ego boost of looking very, very clever. Even if it sounds obvious, it's a hard choice - there are rewards for being seen as very, very clever, and fewer for making things look so simple a child could do it. In a sense, the incentives are set up wrong.
NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: Reading and Writing and Programming
Let them work on the previous students' code. But the first to write should participate in this course.> What a great blog that is!
> I agree with everything he says except I don't really
> see much code that looks "too encapsulated."
>
> The point about college classes only teaching writing
> and not maintaining code is a great one. It's just
> incredibly disappointing that CS majors spend most of
> their time writing code rather than maintaining
> code.
>
> I'd love to put together a college course called
> "real-world software development". I'd give the
> students an impossible deadline, vague requirements,
> and make them all work together from an existing code
> base. In the middle, I'd change the requirements, and
> add a few more requirements. I'd make sure they had
> to find and fix existing bugs as they worked. I'd
> have them switch responsibilities in the middle and
> have one or two people "leave the project" and one or
> two join.
>
> In the end, I would have each student take over
> someone else's code, and the studen't grade would be
> based 30% on whether it worked or not, 30% on what
> the student taking over the code thought of the code
> quality, and 40% what I thought of the code quality.
> I bet you'd see more comments than code
> imagine that poor undergrad trying to decide whether
> to use his own pet naming convention that no one else
> likes.
>
> Oh, and of course if you're not doing well or your
> fellow students don't like you, you may very well get
> kicked out of the class, perhaps with two weeks
> notice.
Re: Reading and Writing and Programming
"Real programmers don't comment their code. If it was hard to write,it should be hard to understand."
Get the RMI Plugin for Eclipse