|
Afraid not, those numbers are correct. ....I'll bring the mop!
nothing
|
|
|
|
|
static void lpf_Null(void)
{
}
Mark Brock
"We're definitely not going to make a G or a PG version of this. It's not PillowfightCraft." -- Chris Metzen
|
|
|
|
|
Is that function used inside the application or it was created just for a better and larger number of lines?
I have no smart signature yet...
|
|
|
|
|
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 .
Mark Brock
"We're definitely not going to make a G or a PG version of this. It's not PillowfightCraft." -- Chris Metzen
|
|
|
|
|
Agreed. State machines often need a null action when only the state transition is wanted. I've written plenty of 'em over the years, particularly in comms protocol implementations.
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Peter_in_2780 wrote: I've written plenty of 'em over the years
Has your implementation matured over the years? I bet it must be close to perfect by now!
|
|
|
|
|
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]
|
|
|
|