# Is Shortening Cell Addresses Valid?

In Excel, Excel VBA, and Google Sheets cell (and range) address may be redefined by the user as special Named Range objects, is the use of these objects allowed by default - that is, may it be assumed that cell A1 is renamed to A and Cell B1 is renamed to b by default such as is done in this answer?

# No, Unless done programmatically

It is invalid to assume that the user has manually redefined a given range to a shorter name. You may, however do so programmatically as part of your answer. An example of valid code renaming range [A1] to [A] in VBA is included below

ActiveWorkbook.Names.Add"A","=A1"

• Move your reason here – l4m2 Dec 18 '17 at 23:52
• or if the bytecount is counted for the .xls(x) file, not just the formula. No one would want to that, however. – user202729 Dec 19 '17 at 1:33
• If use bytecount, lots of submissions would have the same size, for some alignment – l4m2 Dec 19 '17 at 5:48
• @user202729 - the community has decidedly voted against that and instead decided to limit what counts as an Excel or similar language - part of which includes not allowing anything but keyboard input – Taylor Scott Dec 19 '17 at 12:40
• @TaylorScott And you seems to misunderstood me - I meant measure the bytecount of the saved worksheet file. The file stored on hard disk. Of course no one want to do that. – user202729 Dec 19 '17 at 12:43
• @user202729 I understood what you meant, I was just pointing out that the community has voted against counting Excel, Minecraft, Google Sheets and several other languages' bytecounts in this manner – Taylor Scott Dec 19 '17 at 12:45

# Yes.

When really using Excel formula, the source values are usually not in A1 A2 B1 or anything. To make it clear we use name to mean the source. Thus if A1 is allowed, a should

• The problems that I see with this are two-fold: 1 - it requires user action that is neither self explanatory to someone who does not know these languages nor standardized, which leads to confusion in implementation and 2 - It corresponds to a distinct programmable action that you are bypassing without contributing anything to the bytecount – Taylor Scott Dec 18 '17 at 22:27
• And believe me, I would benefit from this being a change - at the time of writing this, I have 230 answers written in Excel, Excel VBA and/or Google Sheets - but I feel strongly that this is does not operate within the spirit of code golf and would only serve to add confusion to these languages – Taylor Scott Dec 18 '17 at 22:30
• For the programable it doesn't hurt, as long as you don't use ROW or anything that related to the position. – l4m2 Dec 18 '17 at 22:52
• I just post the opinion, and do no vote here. I guess you voted – l4m2 Dec 18 '17 at 22:53
• You should have a common standard on languages, not choose the longer one on each. For C or anything you are not allowed to assume value stored in variable t, and in Excel you shouldn't assume value stored in A1 – l4m2 Dec 19 '17 at 5:57
• while, yes in theory it would be nice to handle all languages the same, it is entirel impractical for a site that handles so may esolangs - for instance Piet, Brainf**k, Minecraft, Chess, VBA - they are just so different that they can't be held to the same standards. This is the core reason why I have added so many answers to the VBA Tips page – Taylor Scott Dec 19 '17 at 12:54
• As for the "prior data" in a specified cell, that really not the intention, and in fact that interpretation would be disallowed as a standard loophole; Rather specifying a cell within the formula is just the STDIN (standard input) for Excel and Excel VBA - you can think of it more as you first write the formula then you take the user input via those specified cells. – Taylor Scott Dec 19 '17 at 13:00
• Further, cells in the range A1,B1 ... are chosen as the defaults simply to simplify reading formulas in these languages, so if the problem statement species an ordered tuple of 2 arguments the reader may safely assume that A1 represents the first element in the tuple and B1 represents the second – Taylor Scott Dec 19 '17 at 13:03