|
MarkBrock wrote: No its used as a handler function in a state machine.
The function is really just a bi-product of the design... but still... I thought it was funny .
Actually, I frequently used the same technique when I was programming in C - empty functions made good initializers for function tables, and if I wanted to track function calls all I had to do was add a trace of some sort to the empty functions.
|
|
|
|
|
Doing nothing is considerably better then doing some of the things that show up on this board 
|
|
|
|
|
I have to agree. The man that wrote it is clearly some sort of relative genius.
|
|
|
|
|
I've created a few of those myself - sometimes it is a much better way than providing a special case. Think delegate that doesn't need a null test, for example.
At least it had a sensible name!
Did you know:
That by counting the rings on a tree trunk, you can tell how many other trees it has slept with.
|
|
|
|
|
lpf_NoOp might be a better name.
|
|
|
|
|
PIEBALDconsult wrote: lpf_NoOp might be a better name.
From a logical perspective, I think the meaning and intention of "ptr = lpf_Null;" may be a little clearer than lpf_NoOp;" especially if there are places where the pointer will be checked against lpf_Null, but there are also places where it would be desirable to call it without having to check for the null case.
|
|
|
|
|
There is nothing wrong with an explicit "do nothing". A NOP (No Operation) instruction exists in most micro-processor instruction sets, so you can replace a normal instruction (with N bytes of code), by one or a number of NOP instructions without having to move the instructions that follow.
Similarly, you can create a NOP method, so you can have an array of delegates, some of them possibly just calling your "does nothing" method.
And finally, such a stub can be used to add breakpoints, logging, or whatever is appropriate in the application domain.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
I guess you come across things such as there rather a lot, but I'm still O_o at it
if ( count( $this->m_query->sortkeys ) > 0 ) {
$psort = '';
$porder = '';
$first = true;
foreach ( $this->m_query->sortkeys as $sortkey => $order ) {
if ( $first ) {
$first = false;
} else {
$psort .= ',';
$porder .= ',';
}
$psort .= $sortkey;
$porder .= $order;
}
if ( ( $psort != '' ) || ( $porder != 'ASC' ) ) {
$params['sort'] = $psort;
$params['order'] = $porder;
}
}
Can has implode[^]?
|
|
|
|
|
|
No, it's the language with the most consistent function behaviour - php.
|
|
|
|
|
Nice one today:
'Not as strange as it looks, the property set adds the object to session
MemberData = MemberData
you know what? It really works.
|
|
|
|
|
Maybe that should be in the constructor?
|
|
|
|
|
I don't know what language that's in, but I'm wondering if relying on the side-effects of assigning a member to itself is a good idea. A compiler (assuming this is compiled code) might reasonably optimize that away.
However, you have to like the comment!
|
|
|
|
|
I assume its C# and a property. Then its a normal method call for the compiler.
|
|
|
|
|
comments with ' ... looks like VB or so ...
|
|
|
|
|
|
Well ok.
But even if its VB.Net its still the same.
On the other hand its total crap to abuse a property in this manner.
|
|
|
|
|
Robert Rohde wrote:
On the other hand its total crap to abuse a property in this manner.
Although such code should never be used outside a class, since it relies upon the class not to implement caching behavior (or else relies upon some class-specific means of overriding such behavior), setting a property to itself may be a reasonable way of forcing a refresh of a corruptible copy of a property from a stable one.
For example, one might have an object which manages a USB-connected lighting controller. Setting the "Brightness" property of the object will send a command to the controller to change the brightness. If external factors might disrupt the brightness setting of the external controller, it may be desirable to periodically set the brightness to the value the computer expects. If the property-set routine simply wraps a SetHardwareBrightness method, it would probably be better to call that method than set the property to its present value. If the property-set routine does the actual work itself, however, it's probably better to use the property-set routine for the refresh than to split out a new SetHardwareBrightness method.
|
|
|
|
|
Now if that were C++ and I had also written a copy constructor for the class, I'd be able to introduce some side effects that would be truly humourous. Assign NULL to some pointers, initialize some other variables. Probably make it to Coding Horrors. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
|
I try to remember to do a Find All Usages in Resharper (now in VS2010) to make sure that code inside the class doesn't use the property, only the backing field. Keeps me from writing code like that.
It goes without saying that any code outside the class shouldn't even have any idea what side-effects might be happening in a public setter.
Before .NET 4.0,
object Universe = NULL;
|
|
|
|
|
I found this pearl while doing a peer code review. This is not the actual code but it gave the "idea"...
typedef struct
{
bool m_bUsed;
} CONFIG;
#define MAX_CFG 10
static CONFIG g_vConfigurations[MAX_CFG];
...
bool IsUsed ( int iHandle )
{
if ( g_vConfigurations[iHandle ].m_bUsed == true )
return true;
else
return false;
}
A logic genius... And notice the lack of argument value check before using iHandle in IsUsed() function  .
Bye By(t)e 
|
|
|
|
|
Yeah, I've done that before, then looked back at my own code and said: WTF?
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
That's pretty much the reaction I have to any code I write.
|
|
|
|
|
I don't really mind code of the form
if (condition)
return 1;
else
return 0;
While it certainly could be replaced by:
return (condition) != 0;
the first form makes clearer that what's being handled isn't just data, but control information. I don't like comparisons with 'true', though, unless there's a clear and explicit reason, which should be commented (e.g. 'If "condition" has an invalid value, it got glitched, so return zero to show failure.').
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
