Programming

Create an application which is compatible with Microsoft(r) Windows(c) operating system (i.e. Utility Programs, Edutainment and Entertainment applications, Intranet and Internet applications), GNU/Linux, FreeBSD or Apple MacOS X etc.

You may use any programming language (or scripting languages) you wish (C++, C#, Java, Pascal, ASP, ASP.NET, PHP...etc). Applications are at the base of computer usage. For the end-users, they represent their main gateway to technology. It is crucial that an application has usability and a proper easy-to-use interface as well as functionality. But of course, none of these matter if the key element is missing: a good idea.

If you think you're up to the challenge and are able to create a working program from top to bottom you should definitely give it a try!

This category is opened for all students: secondary, high school and university (for university students this category is judged together with the hardware control category).

Good Programming Practices: What to Do (or Not)

• Be consistent with formatting. I don't care whether you use spaces or tabs for indentation (okay, I do care, but that's a subject for a different article), as long as you stick with one or the other. There's nothing worse than code that is difficult to read because it is poorly formatted. 

• Be consistent with naming conventions. Again, consistency is more important than the specific style you use. Do you name your variables $bean_counter, $beanCounter or $BeanCounter? I really don't care; just pick a style and be consistent. (Of course, only a n00b would use the same style for every type of variable; let's hope you're smart enough to use one style for local variables, another for class names, etc.) 

• Use globals sparingly. Global variables suck. ‘Nuf said. 

• Consolidate literals. Literals belong in a centralized spot (e.g. a separate module or a database), not sprinkled liberally throughout your code. That means you should refer to them symbolically (i.e. by name, not literal value). 

• Don't assume output formats. Sometimes data will get output to the screen, other times to a printer, and other times it will get logged to a database. So why are your low-level functions returning their output in HTML format (or, worse, printing them)? They should be returning values that the caller can have its way with; it's the caller's job to decide whether data will be returned as-is, reformatted, sent to stdout, or whatever. 

• Comment. Add comments to your code in plain English (or your native language if the other programmers who will be reading it also speak the same language) that describe both what the code is doing and why you decided to do it one way and not another way that somebody reading the code might think of on their own. Oh, and don't get all cutesy with your comments; other programmers who read your code just want to fix your stupid bugs; your pithy comments only serve to distract and confuse them.
• Check return values for error conditions. Just because you tried to open a file (or write to it or close it) doesn't mean you were successful. Everywhere you call a function that can throw an error, you should add code to deal with that potential error.
• Provide useful error messages. Expanding on the previous point, you should provide a user-friendly error message while simultaneously logging a programmer-friendly message with enough information that they can investigate the cause of the error.
• Separate business logic from other program logic.
• Separate code from data. OO is only the tip of the iceberg here. I'm talking about things like separating HTML from PHP, Perl or C code.

  Conclusion

  No programmer can ever implement all of these suggestions 100% of the time. Not only does one reach a point of diminishing returns, but also there will always be areas that are open to interpretation, opinion, and individual style. 

  But just because perfection isn't achievable doesn't mean you shouldn't strive for it. In fact, the most important thing you can do is to identify the area(s) listed above where your program is most lacking and take steps to fix it. For example, your program might have excellent database handling routines but your variable names may be completely unintuitive. 

  Half the battle is figuring out (and admitting) where your program needs improvement; the other half of the battle is doing something about it.

  http://www.kmoser.com/articles/Good_Programming_Practices.php

The only way for errors to occur in a program is by being put there by the author.  No other mechanisms are known.  Programs can't acquire bugs by sitting around with other buggy programs.  ~Harlan Mills.

• Photography
• Programming
• Digital Content
• Hardware Control
• Computer Art
• Login