ACCU :: Professionalism in Programming

ACCU Menu

Membership

Login

ACCU Buttons

Add them to your site:

Professionalism in Programming, from CVu journal or CVu Journal Vol 16, #1 - Feb 2004

Browse in :

All > Journal Columns > Professionalism
All > Journals > CVu > 161
All of these categories

Options:: View Article Map; View Archives

Francis’ Scribbles
Description :

Repository of Projects

We need to program in order to develop our programming skills. Anything more than the most trivial program takes time and effort. Most students (in the broadest sense of someone who is studying) find it hard to motivate themselves with projects whose end product is of little use or interest to them. It is much easier to put in the hours doing a job properly if the result is something we have a personal interest in.

Category: [ CVu Journal Vol 16, #1 - Feb 2004 | Francis' Scribbles from CVu journal ]

Letter to the Editor
Description :

James,

I thought it was about time I wrote and introduced myself to ACCU members – it’s probably long overdue given that I’ve been production editor for the journals for a couple of years now (just over two years for Overload and eighteen months for C Vu, to be exact).

Source : Entered by hand
Category: [ CVu Journal Vol 16, #1 - Feb 2004 | Letters to the Editor ]

Professionalism in Programming #24
Description :

“There is more to life than increasing its speed” - Mahatma Gandhi

We live in a fast food culture. Not only must our dinner arrive yesterday, our car should be fast, and our entertainment instant. Our code should also run like lightning. I want my result. And I want it now.

Ironically, writing fast programs takes a long time.

Optimisation is a spectre hanging over software development, as W.A. Wulf observed. “More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity”.

It’s a well-worn subject, with plenty of trite soundbites bounding around, and the same advice being served time and time again. But despite this, a lot of code is still not developed sensibly. Programmers get sidetracked by the lure of efficiency and write bad code in the name of performance.

In these articles we’ll address this. We’ll tread some familiar ground and wander well-worn paths, but look out for some new views on the way. Don’t worry – if the subject’s optimisation it shouldn’t take too long...

Source : Entered by hand
Category: [ Programming Topics | CVu Journal Vol 16, #1 - Feb 2004 | Professionalism in Programming, from CVu journal ]

do...while
Description :

What can be said about C’s everyday do...while loop? It just does something while some condition holds. End of story, right?

No, of course not. That would make the title of this small article silly, so let’s cover two topics.

Category: [ Programming Topics | CVu Journal Vol 16, #1 - Feb 2004 ]

Code in Comments
Description :

We have all seen comments in source files which look more like executable code than documentation.

The first line in the body of the for loop below is such a comment: you might expect to be able to remove the leading slashes and have code which compiles and runs, but functions slightly differently.

What did the author of this comment intend?

Example 0

for (Surfaces::iterator sf = surfaces.begin();
     sf != surfaces.end();
     ++sf) {
  // std::cout << "Drawing: " << *sf << "\n";
  sf->draw();
}

OK, I’m being disingenuous. I’m aware that the comment isn’t really a comment, it’s commented-out code. And, like any tolerant and capable programmer, by examining the surrounding context I can guess why this code has been commented out.

This article examines how to comment out code, then describes various problems which lead to code being commented out, before finally arguing that there’s often a better solution to these problems.

Source : Hand entered.
Category: [ Programming Topics | CVu Journal Vol 16, #1 - Feb 2004 ]

Comment on “Problem 11”
Description :

The first step here in finding problems in the code is to identify the problem the code is trying to solve. The discussion in the C Vu article is basically about curiosities in the way in which the C++ standard library std::istream is defined, but I will make the perhaps unwarranted assumption that what the problem the code is really about is not the uses of std::istream, but rather, more generally, how to write a read routine that can effectively and safely capture data from an input stream. Actually as the first problem below illustrates neither of these issues can be effectively addressed without the other.

Category: [ Programming Topics | CVu Journal Vol 16, #1 - Feb 2004 ]

Student Code Critique Competition 26
Description : This item is part of the Dialogue section of C Vu, which is intended to designate it as an item where reader interaction is particularly important. Readers’ comments and criticisms of published entries are always welcome.
Category: [ Programming Topics | CVu Journal Vol 16, #1 - Feb 2004 | Student Code Critiques from CVu journal. ]

Professionalism in Programming #23
Description :

To err is human.

Category: [ CVu Journal Vol 15, #6 - Dec 2003 | Professionalism in Programming, from CVu journal ]

Professionalism in Programming #22
Description :

Finding fault.

Category: [ CVu Journal Vol 15, #5 - Oct 2003 | Professionalism in Programming, from CVu journal ]

Professionalism in Programming #21
Description :

Software architecture

Category: [ CVu Journal Vol 15, #4 - Aug 2003 | Professionalism in Programming, from CVu journal ]

Professionalism in Programming #20
Description :

Software evolution or software revolution

Category: [ CVu Journal Vol 15, #3 - Jun 2003 | Professionalism in Programming, from CVu journal ]