How to avoid asking trivial questions in forums and mailing lists ?
01/11/03 18:59
A little strategy guide to avoid asking the next trivial question…
If your problem is related to any runtime event:
- compile your project in the Development mode to be sure the compiler writes out warnings;
- read EVERY warning and try to understand what's producing it, and try to fix it unless is really minor (like "defined but not used" ones, but even for these apparently harmless ones, check if the cause is not a spelling error, a misused pragma (#if, #ifdef, …);
- if the problem is at customer site and you can't reproduce it on your machines: think about everything is installed on a developer machine that's not on a "normal" end-user one (like BSD sub-system and the likes…). Look at piece of your code that may depend on some System Preferecences setting;
- track down every piece of your code where you may have hardcoded things that may be dependant on localization (French, German, …) or the way text is entered (text scripting system) by the end user;
- think also about everything that your application may not have access to when run on another machine (file and folder permissions are a classic source of problems) or when run by a non-admin user;
- be careful with constant CFString/NSString like @"abc" and non-ASCII characters. (gcc3.3 outputs warning about these);
- are you checking every error that the OS may be returning to your code ?
- make sure the program is not crashing in your own debugging code ! Check the parameters of NSLog and printf: any "%@" with a C-string as parameter or any "%s" with a NSString (or any id) parameter may lead to unexpected results.
- use the available debugger tools to check memory leaks, zombies, etc. Read NSDebug.h and check if turning on some features may not help revealing the source of the problem;
- if you need to trap signals, think twice about the consequences of trapping signals in "somebody else" code, like system libraries or frameworks (example: trapping SIGPIPE in an application using RendezVous…);
- when using exception handling or any longjmp mechanism, be sure the handling code makes all the necessary clean-up (re-setting some variables that may have been changed, closing files, etc.) and make sure you don't jump outside a code structure that needs balancing like a lock/unlock pair, a begin/end structure (like glBegin/glEnd in OpenGL);
- be careful with little "spelling" detail in @selector parameters: @selector(myMethod) is not the same as @selector(myMethod:);
If your problem is related to a "how to" question:
- Check the class documentation:
Obvious ? Not always, some documentation is in html, other in pdf (like the Objective-C one), … sometimes the doc on the hard disk is not up-to-date and you have to check the latest one on Apple site… Sometimes the answer is not in Cocoa but in Carbon or even in Unix documentation…
You may use Cocoa Browser to browse the documentation, a must-have one, it's GPL-ed…
- Check the superclass documentation:
Forgetting to look at the superclass documentation is one of the most common mistake of the newbies. Apple doc always refer to the superclass at top of the page but never speak about inherited methods if they are not overriden by the subclass, … so be warned;
- Check the protocol definitions;
A lot of classes are extended by protocols, don't forget to check them !
- If you have problem with Cocoa classes having mutable and non-mutable version, be sure you are using the right one: this is often the source of "my data is not saved on disk" questions;
- Check the archives; the Internet forums, the variouses Cocoa-related sites :
OmniGroup, Mac OS X hints, Mac 4 Ever, Cocoa-X, Marc Liyanage , GNU step, Karelia, Cocoa Dev, Cocoa Dev Central, Open Darwin, Hyper Jeff, StepWise, etc
- Use Google !
- Look at OpenSource software supposed to do similar things…
- Avoid to use undocumented features or API, low-level tricks and hacks you are not sure to fully understand or if you are not able to test at runtime the availibity of the resources needed by these tricks.
If still not resolved, ask to a forum or list… choosing the right one for your problem (click here for Apple managed ones).
Include everything is of interest (like some lines of source code, system version, etc.) for people who will try to help you, don't post attachment: most mailing lists and forum management software will remove them. If you need to show screen dumps or make available a compiled application: put it on a ftp site available to other (like your iDisk).
- compile your project in the Development mode to be sure the compiler writes out warnings;
- read EVERY warning and try to understand what's producing it, and try to fix it unless is really minor (like "defined but not used" ones, but even for these apparently harmless ones, check if the cause is not a spelling error, a misused pragma (#if, #ifdef, …);
- if the problem is at customer site and you can't reproduce it on your machines: think about everything is installed on a developer machine that's not on a "normal" end-user one (like BSD sub-system and the likes…). Look at piece of your code that may depend on some System Preferecences setting;
- track down every piece of your code where you may have hardcoded things that may be dependant on localization (French, German, …) or the way text is entered (text scripting system) by the end user;
- think also about everything that your application may not have access to when run on another machine (file and folder permissions are a classic source of problems) or when run by a non-admin user;
- be careful with constant CFString/NSString like @"abc" and non-ASCII characters. (gcc3.3 outputs warning about these);
- are you checking every error that the OS may be returning to your code ?
- make sure the program is not crashing in your own debugging code ! Check the parameters of NSLog and printf: any "%@" with a C-string as parameter or any "%s" with a NSString (or any id) parameter may lead to unexpected results.
- use the available debugger tools to check memory leaks, zombies, etc. Read NSDebug.h and check if turning on some features may not help revealing the source of the problem;
- if you need to trap signals, think twice about the consequences of trapping signals in "somebody else" code, like system libraries or frameworks (example: trapping SIGPIPE in an application using RendezVous…);
- when using exception handling or any longjmp mechanism, be sure the handling code makes all the necessary clean-up (re-setting some variables that may have been changed, closing files, etc.) and make sure you don't jump outside a code structure that needs balancing like a lock/unlock pair, a begin/end structure (like glBegin/glEnd in OpenGL);
- be careful with little "spelling" detail in @selector parameters: @selector(myMethod) is not the same as @selector(myMethod:);
If your problem is related to a "how to" question:
- Check the class documentation:
Obvious ? Not always, some documentation is in html, other in pdf (like the Objective-C one), … sometimes the doc on the hard disk is not up-to-date and you have to check the latest one on Apple site… Sometimes the answer is not in Cocoa but in Carbon or even in Unix documentation…
You may use Cocoa Browser to browse the documentation, a must-have one, it's GPL-ed…
- Check the superclass documentation:
Forgetting to look at the superclass documentation is one of the most common mistake of the newbies. Apple doc always refer to the superclass at top of the page but never speak about inherited methods if they are not overriden by the subclass, … so be warned;
- Check the protocol definitions;
A lot of classes are extended by protocols, don't forget to check them !
- If you have problem with Cocoa classes having mutable and non-mutable version, be sure you are using the right one: this is often the source of "my data is not saved on disk" questions;
- Check the archives; the Internet forums, the variouses Cocoa-related sites :
OmniGroup, Mac OS X hints, Mac 4 Ever, Cocoa-X, Marc Liyanage , GNU step, Karelia, Cocoa Dev, Cocoa Dev Central, Open Darwin, Hyper Jeff, StepWise, etc
- Use Google !
- Look at OpenSource software supposed to do similar things…
- Avoid to use undocumented features or API, low-level tricks and hacks you are not sure to fully understand or if you are not able to test at runtime the availibity of the resources needed by these tricks.
If still not resolved, ask to a forum or list… choosing the right one for your problem (click here for Apple managed ones).
Include everything is of interest (like some lines of source code, system version, etc.) for people who will try to help you, don't post attachment: most mailing lists and forum management software will remove them. If you need to show screen dumps or make available a compiled application: put it on a ftp site available to other (like your iDisk).