How do I force tabstat to display the full name of a variable? The upper limit of 16 characters looks arbitrary in tabstat.ado.

[Michael Anbar]

From what I can tell, the -tabstat- command limits the display of variable names to at most 16 characters, even when using the -varwidth- option. Is there a way to force -tabstat- to display the full name of the variable? Looking at the code in tabstat.ado, the upper bound of 16 characters is hard coded and (appears) arbitrary. If I change this segment of code:

        if `varwidth' == -1 {
                local varwidth 12
        }
        else if !inrange(`varwidth',8,16) {
                local varwidth = clip(`varwidth',8,16)
                dis as txt ///
            "(option varwidth() outside valid range 8..16; `varwidth' assumed)"
        }

to this

        if `varwidth' == -1 {
                local varwidth 12
        }
        else if !inrange(`varwidth',8,32) {
                local varwidth = clip(`varwidth',8,32)
                dis as txt ///
            "(option varwidth() outside valid range 8..32; `varwidth' assumed)"
        }

the command now supports variable names of up to 32 characters in length. Is there a better way to force -tabstat- to display full variable names, besides redefining the command (e.g. tabstat2.ado)? Is there a reason why this command limits the display of variable names to 16 characters, when Stata supports variables with names up to 32 characters? I haven't looked through the code to tabstat extensively, so maybe the reason is buried there, but upon first inspection, this limit looked completely arbitrary.

If this is an arbitrary choice, I'd love it if the next update to Stata 13 tweaked this to increase the upper bound to 32 characters, in line with Stata's variable name policy. It seems like it would be a trivial change.

[Nick Cox]

You can force full variable names by making your variable names shorter.... I predict that you won't like that answer.

The reason for the restriction is, I guess, that tabstat can show many columns and so real estate is often limited. Also, tabstat is a few versions old and written with smaller monitors in mind than now are on some desktops. That said, more people are using laptops, etc. so it's not clear that wider tables would always be visible. .

If you changed Stata's official code, it's a good idea to rename the command and put new ado and help files in your own space.

[Michael Anbar]

You can force full variable names by making your variable names shorter.... I predict that you won't like that answer.

The reason for the restriction is, I guess, that tabstat can show many columns and so real estate is often limited. Also, tabstat is a few versions old and written with smaller monitors in mind than now are on some desktops. That said, more people are using laptops, etc. so it's not clear that wider tables would always be visible. .

If you changed Stata's official code, it's a good idea to rename the command and put new ado and help files in your own space.

I understand why abbreviating variable names is useful, due to screen real estate, but that doesn't answer why there isn't even an option to display variable names up to the full length that Stata allows. I'm perfectly happy for the default value of the -varwidth- option to remain at 12, but the issue of screen real estate doesn't answer why the upper limit is hardcoded at half the length of Stata variable names.

The point of program options is to allow flexibility, and in this case, the -varwidth- option does the exact opposite and imposes an unnecessary restriction, and based on the code, it looks trivial to make the option more flexible, without affecting the default option in any way.

As I mentioned in my original post, I can use something like -tabstat2.ado- that allows for this, but I'm trying to understand why this restriction is in place, since screen real estate explains why the default is the way it is, not why the option doesn't even allow longer names. Sorry, but those issues seem almost orthogonal to me.

[Nick Cox]

StataCorp don't usually leave explanations for such choices lying around, and I can't add to my earlier speculation.

Your argument does look sound to me: let the user decide.

[Michael Anbar]

Is this something that Statacorp is usually amenable to changing? I realize it's minor, but it seems like a simple tweak of the tabstat.ado file to be pushed out in a later update would solve the problem. Unless people have code that relies on the table output to automatically abbreviate long(er) variable names, I can't see how this would be a breaking change either.

[Nick Cox]

I'd just send this in to StataCorp as a comment to technical support. They'll forward it to the developers' list of user requests.

As for StataCorp attitudes, I can't speak on their behalf, but there's a spectrum from bugs that should be fixed as soon as possible to suggestions where StataCorp just disagree politely and will decline to change things. Where this suggestion lies is for them to say, naturally. Typically, if something will be fixed soon, users are told that.