2014-01-11 75 views
3

我正在爲我工​​作的公司寫作SQL編碼標準。領先逗號或尾隨逗號?

我讀過文學,指出leading is the best option

select a.name 
     ,a.surname 
     ,a.address 
from person a 

但也尾隨:

select a.name, 
     a.surname, 
     a.address 
from person a 

non standard at all

select name, is_disabled, 
is_policy_checked, is_expiration_checked 
from sys.sql_logins; 

我的第一個問題,是否有任何SQL編碼標準全世界接受。如果不是,爲什麼不呢?我認爲這將是令人難以置信的有用的。像PEP8一樣。

而哪個將是解決這個問題最實際的方法?

在此先感謝

+2

有沒有一個標準?或許不是'正式',儘管最後看到逗號更常見。這就是說,我在開始時更喜歡逗號。它更具可讀性,我不太可能忘記逗號。我有一些特別的風格,這裏有些討厭,但它適合我。 – Strawberry

+1

我非常喜歡逗號。我是一個人,沒有書面語 - 就我所知 - 在言語之前加上逗號。 –

回答

0

對於如何編寫SQL代碼沒有單一標準。有的使用大寫關鍵字,有的使用小寫字母。一些使用尾隨逗號,一些使用逗號,一些將所有的值放在同一行。

在正常文本中,您使用尾隨逗號,以便大多數人更容易閱讀。使用前導逗號的一個優點是最後一個項目的格式與其他項目不同,但另一方面,第一個項目的格式不同。

解決這個問題的實際方法是在你所屬的組織中選擇一個合理的標準,並堅持下去。具有一致外觀的代碼比試圖找到具有最多優點和最小缺點的格式更有用。

只是作爲一個例子,這是我來使用,經過多年的嘗試不同的變化的格式:

select 
    p.Name, 
    p.Surname, 
    a.Street, 
    a.Zip, 
    a.City 
from 
    Person p 
    inner join Address a on a.AdressId = p.AddressId 
where 
    p.PersonId = 42 
4

如果查詢分析和執行沒有任何錯誤。這意味着它符合該語言的基本標準。

至於在哪裏放置逗號以及如何將您的代碼縮進到其個人喜好。

是的,有一些最佳實踐被人們所定義,大多數人再次將其視爲「最佳實踐」,但並非全部。

有一些最佳實踐,大多數人會同意但不是全部。

1)事情是聰明的,但不能太聰明(KISS /保持簡單 愚蠢)

2)解析的查詢是不是最好的查詢,嘗試寫 Covering Queries當過可能的。

3)爲您的對象使用至少兩部分名稱,如[架構]。[表名]

4)對象 (表,列,存儲過程)變量和函數以及 命名和意義,而不必想太多。

5)你回來給它的週末休息後,你可以直接跳到在

6)事情需要再次使用可重複使用

7)代碼 看起來比較清爽。將在後期更容易調試和修改。

8)「註釋」使用註釋來解釋一段代碼做了什麼, 所以如果你一個月打完回來它,你就會知道剛剛 閱讀註釋代碼做什麼而不是實際發生 通過代碼本身。

9)資金使用像關鍵詞 「 SELECT,FROM,WHERE」 - < -

保持所有這些事情記了上面的查詢我會寫這樣的事情。

SELECT A.NAME 
     ,A.SURNAME 
     ,A.ADDRESS 

FROM PERSON A 

回到「重要問題」引出的逗號或尾隨逗號?

我個人發現在我的代碼中包含前導逗號更容易,因爲它使我更容易找到下一列的起始位置或找到丟失的逗號。

例如在下面的查詢我的回答對堆棧的問題之一了流動

SELECT  radius 
     , Diameter 
     , CASE WHEN POWER(@p1 - x, 2) + POWER(@p2 - y, 2) <= POWER(radius, 2) 
      THEN 'Inside The Circle' 
      WHEN POWER(@p1 - x, 2) + POWER(@p2 - y, 2) > POWER(radius, 2) 
      THEN 'Outside the Circle' END [Inside/Outside] 
FROM @t 

領先的逗號使得這麼多更容易找到丟失的逗號,如果我有一個明確的告訴如何很多列都有這個SELECT查詢。

一些有用的鏈接

Aaron Bertrand - Best Practices for Stored Procedures

Richard Espinoza SQL Server Concepts and Best Practices to Build Transact SQL Stored Procedures

pinaldave SQL SERVER – Bad Practice of Using Keywords as an Object Name – Avoid Using Keywords as an Object