Is there any difference between putting a column alias at the start or the end of the column definition? I've always seen and written my column aliases as

SELECT 1 as ColumnName


but today came across a query that used

SELECT ColumnName = 1


Is there any difference in how these two queries get executed? Or is there a standard among DBAs about which one to use?

Personally I think the 2nd would be easier to read/maintain for longer column definitions (good example here from this article), however I've never seen the 2nd syntax used before today so am wondering if there is some reason I shouldn't be using it.
There is no difference in the underlying functionality of the two types of aliasing (as opposed to =).  What it boils down to is exactly what you mentioned:  Readability and maintainability.

In my opinion the former (&lt;Expression&gt; as &lt;Alias&gt;) is much more readable as it is self explanatory.  When you have SELECT ColumnName = 1 I think it'd be pretty easy to mistake that as setting a variable on those long tired nights.  You might mistake that as SELECT @ColumnName = 1 and that would be completely different functionality.  Therefore, to circumvent any possibility of the query "double look", or even worse...error in understanding/coding, I go with SELECT 1 as ColumnName 100% of the time.

Personal preference, but consistency (for yourself and within your team) is king.  Whatever you find easiest, go with and do it all the time.  There is nothing more frustrating than switching back and forth for somebody troubleshooting/reviewing/maintaining code.

The third unmentioned way is to use &lt;Expression&gt; &lt;Alias&gt;.  In other words, your second way without the as keyword.  I think this is just as bad as the = symbol.  It lacks readability at the gain of what?  Not typing three extra characters (as and a space).  Not worth it.

For exaggeration purposes, take a look at a query like this:

use AdventureWorks2012;
go

select
    [New Name] = Name,
    NewDepId = DepartmentID,
    GroupName as GName,
    ModifiedDate MyModDate
from HumanResources.Department;


Not code that I'd want to review.