Author : Drew Sikora
Page : << Previous 2
for a lead to be able to read through PDL and decide whether the programmer is on the right track. Of course this won't catch programming flaws, but programming flaws can be avoiding by finding design flaws - so it's all good.
On top of that is the ease of which you can modify PDL - anybody can do it! People who don't know jack about coding but are seasoned designers can easily change the wordings of a routine to better match specification. This is the cheapest and most effective way to change a program architecture. Think of how hard it would be to have to rip out a few lines of code that could easily constitute only one line of PDL. Saving money is always a good thing, and PDL can help you do that.
Part 2: Code Documentation
Ahh, here we go - the reason I decided to write this whole article in the first place. I think another acceptable translation of PDL would be Program Documenting Language. Why? Easy - check out what I did with Example B.
// Prevent the drawing surface from being accessed by other programs while we draw.
lpdds7->Lock(NULL, &ddsd, DDLFLAGS, NULL);
// Retrieve the memory pitch of the surface memory so we do not draw out of bounds.
int mempitch = (int)ddsd.lPitch;
// Retrieve the location of the surface so that we can draw to it successfully.
UCHAR *video_buffer = (UCHAR *)ddsd.lpSurface;
// If the pixel mode is set to random
if (pixel_mode == RANDOM) {
// Create three random values that we can assign to the x, y and color attributes of the pixel.
UCHAR color = rand()%256;
int x = rand()%800;
int y = rand()%600;
}
//Else if the pixel mode is set to linear
else if (pixel_mode == LINEAR) {
// Update the horizontal position of the pixel.
pixel_x++;
// Create a random value for the color of the pixel.
UCHAR color = rand()%256;
} // End If
// Plot the pixel on the screen.
video_buffer[x+y*mempitch] = color;
// Release the surface for general use once again.
lpdds7->Unlock(NULL);
// Return TRUE that the pixel was plotted.
return 1;
Check that out. In all my past experiences I've always coded first, commented second. Who'd ever thought the other way around was better? Obviously somebody did. What an easy way to code and comment at the same time. For all you people against taking the time to comment you code (you'd be surprised how many people actually hate to comment, check out this thread for proof), this is the excuse that you need. You don't even have to think of it as commenting, just write out the routine in PDL to get the architecture and implementation straight, then just code it and don't delete the PDL, because it turns right into comments!
Conclusion
Well that's about it. PDL, as you can see, is a tool than belongs in any designer's and coder's toolbox. I'm sure glad I stumbled upon it, because it's streamlined my coding a lot. Writing out a whole routine in PDL and then just adding the code after perfecting it has saved me countless hours. I hope I did a good job explaining to you the correct way to use PDL to save you time and effort. Any questions and/or comments can be directed to gaiiden@hotmail.com - I'd love to hear from you. Until next time...
Page : << Previous 2