Quote:Original post by truthS
hello I just compiled some code that had no function prototypes above the main function,the functions for only defined above main()like this
_______________________________________
void Slock(SDL_Surface *screen)
{
if ( SDL_MUSTLOCK(screen) )
{
if ( SDL_LockSurface(screen) < 0 )
{
return;
}
}
}
__________________________________________
instead of this:
void Slock(SDL_Surface *screen); <---- a normal prototype
Usually I would see the prototype above main() and the definitions after main(),
I was wondering what the correct standard is?
It doesn't matter if the prototype is before or after main, all that matters is that the function is either prototyped or defined prior to the place that it is called.
Depends on what you mean by not understanding the inner workings. For example, on Windows, most operating system calls are black boxes. The API documentation tells you what they do, but not how they do them. So in that sense you will never understand the inner workings of those, unless you get a job working on Microsoft's operating systems team. On the other hand, a professional will (hopefully) read the available documentation for every function he uses and not just "voodoo program".
If the code you're using is open-source, I would say absolutely learn what it does and how it does it. Knowing this helps you design your code better, and makes it easier to identify and fix problems.
If it's closed-source, learn all you can from the docs and headers. About the best you can do is learn how stuff interacts, and make educated guesses about how stuff is done. For instance, if you see what kind of protected and private functions a class has, you'll be able to reasonably guess what goes on behind the scenes.
In sum, learn everything you can about how the things you use work before using them. It'll make your code better and make debugging easier.
If it's closed-source, learn all you can from the docs and headers. About the best you can do is learn how stuff interacts, and make educated guesses about how stuff is done. For instance, if you see what kind of protected and private functions a class has, you'll be able to reasonably guess what goes on behind the scenes.
In sum, learn everything you can about how the things you use work before using them. It'll make your code better and make debugging easier.
Well... I constantly use classes i've never seen the code sourcecode to. I only see the public interface, so i don't even see what private methods it has.
Now, this is because i work as a part of the team, where the programmers are assigned their own objects, with the specified interfaces. I could of course see the source if i needed to, but since the interfaces are strictly defined there isn't usually a need for it.
So yes, in that sense professional programmers use a lot of code where they don't have a perfect, or in some cases, even decent understanding of.
Now, this is because i work as a part of the team, where the programmers are assigned their own objects, with the specified interfaces. I could of course see the source if i needed to, but since the interfaces are strictly defined there isn't usually a need for it.
So yes, in that sense professional programmers use a lot of code where they don't have a perfect, or in some cases, even decent understanding of.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
