Please forgive my bluntness, but I think you've misconstrued "refactoring" in your statement "The whole point of refactoring is to create clear and easily readble code.".
At the very least, you've carried to a level that I'd bet the originators would classify as harmful and not in keeping with the concept's objectives.

Your argument seems to hinge on the idea that function acronyms are obscure. You propose home-brewed functions with "clearer names" as the solution.

First, I suppose that "constants" would provide a much easier way to solve the "problem".
More importantly, though, your suggestion actually obfuscates the code rather than improving it.
Function "acronyms" (which isn't really what they are, in my opinion) ARE THE LANGUAGE. Surely anyone hiring someone to work on an application will hire someone who KNOWS THE SPECIFIC LANGUAGE. By replacing known functions with homebrews you are confusing the (next) programmer, not helping him.
A fresh programmer will HAVE TO check out each of the home brew functions in order to confirm exactly what they do, that they are indeed properly coded, don't hold any surprises, etc.

Secondly, your home brew functions suit you to a "T" and so the code is "clear and easily readable" TO YOU. The next programmer, saddled with all this extraneous home brew stuff, might legitimately opt to remove it all in favour of real code that everyone understands and TRUSTS. So all you will have accomplished is more work for the next guy.

I've gone and bought the book by Fowler on Refactoring and though I am only on page 7 one thing is clear already, and that is one does NOT refactor for the simple sake of refactoring. There are 'triggers' (my term, being only on page 7 < s >) that prompt the decision to refactor.

Yours is the kind of thing I was very worried about when I initially challenged MartinS on his articles on the subject - that everyone would read it as virtually mandatory to refactor any code they got into AND that they would do so because the code was not in their particular own style.

I remain of the view that refactoring is a carefully considered decision that is highly dependent on the nature of the revisions required, the (code) quality of the application being revised, the (future) longevity of the application, and factors like that. But it most definitely is not undertaken just because the style of the code does not match the style of the current programmer working with the code.
Imagine if every President/Prime Minister/Dictator/etc who came along rewrote the laws of the land to suit their own style!

Jim


>In a recent discussion on creating a primary key, the issue came up of how to convert a date to a string. As is common, VFP provides multiple solutions for the problem. I would like to add some observations on this from a refactoring point of view.
>
>The first and most obvious function for convering a date to character string is
>

DTOC(datefield)

>This will return a caracter value for the date in the form MM/DD/YY. The exact format of the date will be dependant on your settings for
>

SET DATE

>and
>

SET CENTURY

>If as an alternative, you use
>

DTOC(datefield,1)

>The date will always be returned as an 8 character string in the form
>

YYYYMMDD

>This field is not very pretty for display purposes, and I would not use it for that purpose, but it is excellent if you need to create a character string that includes the date along with other character data.
>From the point of view of program clarity, however, I think that the ',1' greatly decreases the clarity of the code. When I look at the line
>

DTOC(datefield,1)

>One of 2 things happen to me, I either miss the ,1 and read it as
>

DTOC(datefield)

>Or I open my help file to figure out what the ,1 does. Either way, this is not clear and clean code. If I need an 8 character, sortable date in a string format, I would use instead
>

DTOS(datefield)

>This would return my 8 character YMD string regardless of the settings for
>

Set Date

>and
>

Set Century

>We are good so far, but now we run into a problem with consistency with time commands. The following commands are valid
>

>TTOC(DateTimeField)
>TTOC(DateTimeField,1)
>

>But, there is no command for
>

TTOS(DateTimeField)

>Thus, while we could use DTOS, there is no corresponding TTOS. My solution here would be to create a new function as follows
>

Function TTOS(DateTimeField)
>Return TTOC(DateTimeField,1)

>By using my TTOS instead of the built in TTOC(DateTimeField,1) function, I mirror the DTOS function for clarity and consistency, while hiding the ,1 parameter from day to day use.
>In fact, I would probably go a step further. The whole point of refactoring is to create clear and easily readble code. Unless you are very familiar with the date/time functions, the acronyms can be obscure. This could easily be resolved as follows
>

DTOC(DateField)

>becomes
>

Function DateToCharacter(DateField)
>return DTOC(DateField)

>

DTOS(DateField)

>becomes
>

Function DateToString(DateField)
>return DTOS(DateField)

>With the expanded names, the purpose of the functions becomes more clear, and the code becomes more easily readable and maintanable. Any parameters are moved down the code tree, where they can be ignored on a day to day basis.
>Once these new functions are built and tested, they would just be stored in a library and available for use in any future coding.