Click here to Skip to main content
15,388,688 members

Comments by John Brett (Top 19 by date)

John Brett 14-Apr-14 12:02pm View
Reason for my vote of 2 \n There are too many better articles on Codeproject already on this subject to rate it well.
What we need are more articles on why not to use singletons.
John Brett 23-Oct-13 11:41am View
Reason for my vote of 2 \n In fairness, the code does illustrate how to use the engine - sort of.
The basic idea has merit, but more explanation is needed, even for a tip.
John Brett 25-Jul-13 7:29am View
Reason for my vote of 3 \n I'm not sure what advantages this tip/code library brings.
There are plenty of other examples of logging, many showing good coding practice. This doesn't appear to demonstrate any notable features.
This library, for example, spectacularly fails to demonstrate good OO design and separation of concern (by hard-coding the file, console and db output types).
John Brett 7-Feb-13 5:04am View
Reason for my vote of 1 \n An impressive case of missing the point.

The example you give has, as its foundation, the lack of a suitable way of declaring an appropriate constraint that the types should support arithmetic operations. Since these are defined as static methods of the class, you can't express the constraint in terms of an interface.

Any code that switches on the type of object passed in is, IMHO, a seminal example of not understanding OOD.

John Brett 21-Jan-13 4:56am View
Reason for my vote of 3 \n Showing async code that uses Sleep statements for thread synchronisation is not a great example.
John Brett 26-Oct-12 5:22am View
Reason for my vote of 3
Your extension method requests all of the custom attributes from the field, then makes the assumption that the first one it finds will be of type DescriptionAttribute. Needless to say, this will fail if your enum uses any other attributes.

It also doesn't address the question of internationalization. A common origin of this requirement is to be able to display a human-readable form of the enum - and that ought to be in the reader's own language.

So not the best implementation of this on CodeProject.
John Brett 22-Oct-12 4:20am View
Reason for my vote of 4
A useful approximation of the in-memory costs of an object.
John Brett 17-Oct-12 3:12am View
Reason for my vote of 4
The information in the tip is useful and well presented.
Supplying the source as a .zipped .rar file is odd and unhelpful - it means we can't browse the source from within codeproject.
As the sample in the tip shows, the code really does have a massive switch statement on the drive letters - surely even for a tip this should have been refactored into a single function?
I'm also not comfortable with the code actively killing explorer's process - that feels wrong and may have unintended consequences.
Anyway, useful content (even if I do have reservations about the delivery).

John Brett 20-Sep-12 6:36am View
Reason for my vote of 3
The aspect of this implementation that I don't like is the confusion between being a state-changing method of a class and being a function operating on passed-in parameters.
It both uses the parameter ref node and this.header (which happen to be the same variable), which makes it unclear what this method is supposed to be.

I agree with FatCatProgrammer that the logic should be extracted and shown in isolation.
John Brett 13-Sep-12 3:16am View
Reason for my vote of 3
This looks more like an article than a tip to me (it's a complete application, rather than just 'how to do').
The issue I have with the coding is the use of
This is widely deprecated, mainly on account of the opportunity for the code to go re-entrant and can lead to a stack overflow.
It looks like you're facing the issue most programmers faced when Windows (et al) first came out - the logical leap from linear coding to event-driven coding.
I'd be much happier with a solution that used events (e.g. a Timer) to iterate through the animations, and lose the DoEvents and Sleep calls.
John Brett 5-Jul-12 12:17pm View
Reason for my vote of 5
Nice, although if you're going to all of this trouble you ought to include a try/finally or using(){} pattern to ensure that you're exception-safe
John Brett 14-May-12 3:56am View
Reason for my vote of 2
First, congratulations on making a working chat program.

However, the code is generally pretty poor, and not something I'd want other people to use as a basis for coding.

Gotos. Seriously? Nowadays, in an OO language? :-(
Global state. Lots of weakly-named variables with global scope in the poorly named Module1.
Using integers for state. We have enums, now.
Using Thread.Abort (and acknowledging that it's poor practice).
Monolithic code. There's very little attempt to break out the various functions of the code, instead building up a few very large functions.

John Brett 5-Mar-12 3:45am View
What is the purpose of placing the restriction upon the implementation?
John Brett 8-Feb-12 4:16am View
Reason for my vote of 2
There are other ways to refresh the browser page than by pressing a specific key. Technically, even that would be browser-specific, although I suspect that there's an informal consistency in key mappings between browsers nowadays.
The only certain way to achieve this is to ensure that the back-end server can cope with receiving the same post more than once (as the OP example demonstrates).
John Brett 10-Jan-12 9:28am View
"I could not find hide nor hair of an algorithm for the Natural Logarithm"
Wikipedia has an article on the subject, including a number of implementations. has a long list of possible implementations. describes the Taylor series implementation in more detail.
John Brett 10-Jan-12 8:56am View
Why not use a numeric updown control?
Your solution, whilst superficially viable, blocks a huge number of common editing operations that a Windows user would reasonably expect to be able to use: delete key, shift+arrows to highlight text, paste, cursor movement, the decimal separator ...
It also is hard-coded to support two decimal places. Whilst this is common, it is not universal.
John Brett 9-Jan-12 10:26am View
In my case, I was writing a massively parallel find routine, operating on multiple regexs on multiple files concurrently. The regexes themselves were user-supplied, but even the most trivial of strings (without any special characters) were many times slower (~x5 from memory).
Hugely unintuitive, and hard to find, therefore worth sharing.
IIRC, Jon Skeet has also blogged about LINQ sometimes having unexpected performance characteristics (either faster or slower than expected).
John Brett 9-Jan-12 9:58am View
BTW - RegexOption.Compiled can have a negative effect when combined with LINQ. I had a case where performance was many times worse, executing a compiled Regex from within a LINQ query vs using an uncompiled version of the same Regex.
So, as always, the golden rule of optimisation stands - measure it (which, of course, you've done for the use-cases you've listed).
John Brett 6-Jan-12 10:49am View
Reason for my vote of 5
Simple and efficient