Chris Ahrendt wrote: > Ivan Gyurdiev wrote: >> Ivan Gyurdiev wrote: >>> James Hawkins wrote: >>>>> context.c - same except in this case its just a return with noting >>>>> else.. >>>>> why do a goto why not just do the return? >>>>> >>>> This is probably ok to change. I can only imagine that the original >>>> author thought there might be cleanup needed at some later point. >>> The bigger question is why there is a huge if-else statement, and why >>> this function is so large. >>> Huge if-else statement = 2 sub-functions >>> >>> Shader dirty constants - do shader internals really belong here ? >>> >>> Ivan >>> >> The GL initialization stuff at the end should also go into a subfunction >> imho. >> It really looks like the core of the function control flow does this, >> unless I'm misunderstanding: >> >> hdc = get_hdc_somehow() [ offscreen and onscreen choices ] >> ctx = create_new_context(hdc) >> switch_context(new_ctx) >> initialize_gl_stuff_in_new_context(new_ctx) >> switch_context(old_ctx) >> >> The rest is unimportant details like making it work properly :) >> >> Ivan >> >> > Ok here is the next question.. do I just rework it into seperate > functions and leave the main API routine alone and just call the > others... whats the process to do something like this? > > Chris >
Unless you are trying to fix something, make it more efficient there is no reason to touch the code just because it looks bad. Some one might have lots of work done on said function and just about to send their changes in. Then come to find out that all of the changes have to be scrapped and rewritten because some one reformatted the code. And it also helps if you actually understand what that piece of code is doing. Some code is kept ugly just so one day it can be properly rewritten not just reformatted. Vitaliy.