Eddy Vluggen wrote:

Third option, my favourite, is to have all changes only in memory, and write them on a "save" method.

Indeed, this way you properly decouple the form(s) from the underlying models in proper MVC fashion.

Sometimes a fist in the face says more than a thousand honeyed words.

Programmers don't all work the same way; even when dealing in static languages and using self-documenting naming conventions, people will take away different meanings at first glance. How about when coming across a moderately sophisticated regex? Surely a one-line comment would explain its purpose quite effectively. It also helps in maintenance/debugging if you can read in plain terms what the developer had originally intended.

Sometimes a fist in the face says more than a thousand honeyed words.

It's a very different flavour of horrible, eye-burning code. One can quite easily write terrible code that somehow manages to run, possibly due to all the goats being sacrificed as fuel. Such abominable code certainly does exist in every language ever made, but it takes a great deal more effort to produce the forsaken mess - even poor programmers tend to give up by then and rethink their approach.

Sometimes a fist in the face says more than a thousand honeyed words.

It's just as well you've had an error like this - hopefully if/when you fix it, you'll have a more structured method for debugging in the future. It is not a good idea to write code with the approach of build and run it hoping it works; you have no idea what could be going wrong under the surface. If I was faced with an empty error dialog, I think my approach would be as follows (Apologies in advance, I'm not familiar with C++ Builder 6)

- Track down 'when' the error occurs. We know it happens as you open the program, so try building some more useful output into the program. It sounds like you're unable to debug line-by-line, so I'd try bringing up an output dialog each time something works properly - print some useful text to say what was done, etc. - Find the offending operation/function that is causing the issue. With the information you've provided, I'd keep an eye out for any file loading stuff that may be involved; perhaps your file loader can only handle absolute paths and it's being fed relative ones. - Replace the suspect code with a simple test - instead of trying to load a file, perhaps output a "Loading file [path+filename]" message. If it doesn't come up with the blank dialog anymore, you know which line causes the issue. I'm far more used to debugging by pressing F10 until it breaks in Visual Studio, so this is effectively a more long-winded approach to doing the same thing. - Fix the offending code. Naturally, you still need to be able to load the file; I'm unfamiliar with your program's requirements, but if it's plain C++ loading a data file (binary or text, usually) then you should have no problems using an input stream[^]. I can promise you that this definitely works, and won't give you blank error messages.

If you find errors in your code, it shouldn't matter if you get nonsensical or unhelpful messages - that's often the flavour of the day when it comes to programming. You need to break it down into each step to find out what's wrong, which inherently helps you understand your own code (or other people's code) better. Happy hunting!

Sometimes a fist in the face says more than a thousand honeyed words.

I'll make a point of saying "I do not disagree with your statement", because clarity is a *very* important part of what I believe defines good code. But I will also point out that good code is, indeed, code that works. This may seem obvious, but having maintainable code that doesn't do the job is of little use; it simply means fixing it is unlikely to take as long as fixing broken spaghetti code. The notion of what makes good code generally falls under the purview of software engineering, à la Gang of Four design patterns and the like. I don't think anyone here has given an incorrect opinion, as all are valid measures of good code; meaningful variable names, concise functions with well-written comments/documentation and low-cohesion to aid maintainability and extensibility are just a few measures of code quality.

Sometimes a fist in the face says more than a thousand honeyed words.

I'd say there is a great deal of variation between different people in terms of what is more effective for their future. Some people are less suited to university, while others don't feel ready for a career when they finish school/college. I reiterate that regardless of their degree and where they studied for it, some people simply aren't suited to particular kinds of jobs. A talented mathematician and coder may struggle on writing database queries, and therefore be seen as a poor programmer when starting a job.

Sometimes a fist in the face says more than a thousand honeyed words.

One does not study Shakespeare for career prospects except, say, in creative writing or (likely theatrical) acting. Also, I daresay most programmers do not study the nuances of the Platonic solids, least of all at university-level. As it happens, some people choose to study a subject because they have an interest in it. Even if a graduate finds their degree to be of little help in finding a job, they will still have matured from several years of the student life. Further, I wouldn't gauge a university's effectiveness or reputation by its number of graduates, nor the quality of programmers it produces. As with all things, programming or otherwise, with a degree or a handful of GCSEs, an individual can find the right job for them if they look in the right places and apply themselves properly. If they are not the right candidate for the job, their choice of education + institute should not be condemned if they are rejected.

Sometimes a fist in the face says more than a thousand honeyed words.

Tom Clement wrote:

I agree that nowadays, it does seem like you need a degree to get in the door.

I'd put that down to the merits of the degree - you have three years of formal education learning how to code, so at the very least one hopes you can pass the technical test before the interview. If you do not have a degree, one assumes you have other things that qualify you for the job, at least to the value of 3+ years of paid study. Sufficient work experience, a comprehensive portfolio, or even key business contacts hooking you up to the right people, etc. are all perfectly valid and recommended methods of getting relevant work. Naturally a combination of the above is all the better. As for (re-)introducing apprenticeship schemes as legitimate door-openers, I'd simply surmise that you mean industry recognition for same; it all comes down to work experience that will help you build a sweet portfolio, land some interviews and pass the tech tests. Whether an employer will view an apprenticeship in the same light as industry experience is another matter.

Sometimes a fist in the face says more than a thousand honeyed words.

'tis said by Linus Torvalds that "If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."[^] While this is a quote from 1995, it is certainly a guideline worth thinking about. When you have many levels of nesting, what are the options? - Collapse your 2D array into a flat array and reference using a multiplicative index (much like the underlying work done with a 2D array anyway) - Call a function when at a given depth, splitting the complexity into separate pieces and cutting the indentation. - Rework the program logic to require less indentation in the first place, such as using external variables or handling exceptions separately. These all have their good and bad points, and as always it depends on circumstances. As people here have pointed out, situations such as iterating across 3D constructs does often require additional levels of indentation to use. It's down to the situation at hand; if it makes things easier to read/maintain, then simplify things where you can. If "simpler" is more twisty and fragmented, then just tolerate the extra indentation and get back to work.

Sometimes a fist in the face says more than a thousand honeyed words.

The biggest problems I have with this awful insightful article are his invalid comparisons: > He half-mentions that you can use if/else rather than switch cases - I have plenty of complaints about the Then keyword, myself. > His complaints about redimensioning arrays bother me especially, "Critics will tell me that [...] I should be using lists and not arrays anyway. That’s hardly the point!". I'd say that this is, in fact, entirely the point; you're using the wrong tools for the task. Use a damned list if you want a resizable collection! Points 1, 4, 7 and 9 are his personal problems with programmer syntax, which are valid opinion pieces but 'not' reasons why VB is better, and points 3 and 5 are his complaints about the editor, not the language. The one point I almost agree with is number 9; C# not allowing a direct conversion between enumerations and integers. I do genuinely find this to be a nuisance, as the whole point of creating an Enum is for more discernable values during debugging whilst keeping the ever-so-tidy integer format. To then require explicit conversions is tedious and feels less elegant, but I'd take that over a language that defines variables with Dim any day. If I were feeling vindictive, I could also point out that if I saw a function named PMT, my first guess would not be the annual mortgage payment of a loan... suffice it to say, one cannot fault C# on its built-in functionality.

Sometimes a fist in the face says more than a thousand honeyed words.

I'd consider myself to be in the young 'un category - several months out of university - but I still have uses for .bat files. Most often, I feel the need to have external libraries (Boost, GLFW and SDL being most common) in one place. So to keep them self-contained and properly referenced in my projects, I have .bat files in their respective folders which simply state

setx BOOST_DIR %CD%

or equivalent thereof. Saves me the effort of dealing with changes when migrating to different workstations, and keeps my projects up to date when the libraries are updated. Naturally this only works for systems where I'm allowed to set environment variables in this manner, but in my naive experience it has served me well thus far.

Sometimes a fist in the face says more than a thousand honeyed words.

if (life == ToBe)
return Question;
else if (life != ToBe)
return Question;

given only two wholly mutually exclusive conditions, this could be simplified to

return Question;

Either Hamlet was overcomplicating his problem or he was a stickler for convolution. Or perhaps it should be taken more literally as

return (ToBe == true);

But no, this is silly - this only takes the first condition and ignores the rest of the system specification. Besides which, it somehow doesn't have the same ring to it this way.

Hmm, surely that misses the advantage of giving optional parameters, i.e. you can call the function without specifying all the input - using this form means you still need to give three values, or it doesn't match the function. Also, in this example, it's impossible to supply 'false' for the third value; false is the default value for a bool, so it would always become true.