> On Wednesday, November 12, 2008 12:08 PM Rob Cameron wrote: > Subiect: Protecting myself from consequences of lack of time/effort > > ..... > > So, I want to build-in to some of these methods a warning to myself to > be > careful how I use them. I have started adding unneccesary string > parameters to > the method definitions, something like this: > > function MyStrTest(TextIn: string; Hey_ASCII_Chars_Only: string = ''): > boolean; >
How about this: function MyStrTest(ASCIIOnlyText:string):boolean; Please be aware that using an extra parameter to the function will make your code less efficient because the parameter will always be passed to the function, even if you don't explicitly write it in the function call. On the other hand you can easily modify parameter names because you only need to look into one unit. All the other units will compile just fine. > > .... > > if MyStrTest(SomeString) then ... > > although I can use it if I want to, as in: > > if MyStrTest(SomeString, '!!% Hey - be careful with this method') How about this alternative: if MyStrTest(SomeString) then (* Hey - be carefull with this method *) - ie: if you want comments, use real comments. On my IDE I always configure comments to show in RED BOLD! This makes them pop out from all the other code. > then ... > > and if I am disciplined about using key sub-strings such as 'Hey_' or > '!!%' I > can quickly search my projects for the warnings. > You can always attach extra information to the function declaration as a multi-line comment. In fact that's the first I'd look at if I wanted more information about a function! You can get really fast to the declaration of the function by holding the Ctrl key down and clicking on the function's name. Compare that to searching throw your projects looking for comments. > The To-do-list could partly solve the problem, but it doesn't show up > when I am > actually using the methods. > > Does anyone have a better solution, or do you all write perfect code > all the > time? :-) Here are a few ideas on how to fix this: (a) Write LOTS of comments in your code. I'm always trying to write exhaustive comments for all units that are likely going to be reused, explaining how the unit should be used. Every single class I write is preceded by an one-line comment (more lines if required) identifying the purpose of the class. If a function's name is not enough to completely identify the purpose of a function I'm adding an one line comment. (b) When you're dealing with functions meant to be reused spend the extra time to make them complete (ie: handle every possible kind of input). If you can't make the function handle every possible input that test for the erroneous input and raise an error! An custom error message would at least give you something you can search for in your projects. If you get a generic Access Violation you're in much deeper trouble. (c) Make use of the "deprecated" attribute. (d) Make use of $MESSAGE - you can use this to generate an hint every time a unit is compiled. This is probably excessive for what you seem to need. -- Cosmin Prund _______________________________________________ Delphi mailing list -> [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
