한동안 Eclipse를 사용하지 않다가... Java 프로그래밍 할 일이 있어서... 올만에

Eclipse 3.0을 다운 받았다.

Lastest Release로는 3.0이 아직 안 나와서 Stream Stable Builds를 받았다. 정확히 3.0M9이다...

단축키가 많이 바뀐건지 내가 까먹은건지 --''

하나씩 발견할 때마다 정리해보고자 한다.

새삼 Eclipse의 강력한 기능이 부럽다... MS도 이렇게 완벽히 만들면 얼마나 좋을까...

혹시 여기 있는거 말고 아시는 분 덧글 달아주심 ㄳ

우리 회사의 ASP 페이지들에서는 Transaction Required를 많이 사용하는 관계로 종종 DTC에러를 접하곤 한다.

워낙 많이 겪어서 이제는 아무렇지 않게 처리하곤 하는데....

일반적으로 알고 있던 방법을 다 동원해도 해결이 안됐었다.

다른 점이 있다면 web과 db server 모두 Windows 2003이라는 점!!

이리 저리 찾던 중 Windows 2003에서 Web과 DB서버의 DTC를 Enable하는 방법에 대한 문서를 찾았다.

파일로 첨부해서 올리겠습니다. 참고 하세요~

원본 링크 : http://support.microsoft.com/?kbid=555017

SQL Server Management Objects (SMO)

The SQL Server Management Objects, known as SMO, is the management object model for SQL Server Yukon. SMO represents significant design and architecture improvements for the SQL Server management object model. It is a simple to use, but rich object model based on .NET managed code. SMO is the primary tool for developing database management applications using the .NET platform. SMO is used by every dialog in SQL Server "Workbench" and every administrative action you can perform in SQL Server "Workbench" can also be accomplished using SMO.

The new SMO object model and the WMI APIs replace SQL-DMO. Where possible, SMO incorporates similar objects as SQL-DMO for ease of use. You can still use SQL Server Yukon Beta 1 with SQL-DMO, but SQL-DMO will not be updated to manage Yukon-specific features.

SMO and SQL-DMO

The SMO object model is a logical continuation of the work done in SQL-DMO. SMO is feature-compatible with SQL-DMO, containing many of the same objects. Where possible, the original SQL-DMO design is followed but SMO has a number of additional features beyond SQL-DMO. To achieve maximum DDL and administrative coverage for SQL Server Yukon, SMO adds more than 150 new classes.

The primary advantages of SMO are in its performance and scalability. SMO has a cached object model, which allows you to change several properties of an object before effecting the changes to SQL Server. As a result, SMO makes fewer round trips to the server, and makes its objects more flexible. SMO also has optimized instantiation, meaning that you can partially or fully instantiate objects. You can load many objects quickly by not instantiating all properties of the objects.

Unlike SQL-DMO, which has a single Application root, that keeps references to all created Server objects, SMO lets you establish multiple roots for servers without establishing a new connection. SMO implements advanced multiple-phase scripting, in addition to supporting SQL-DMO style scripting. You can also switch an object into capture mode, and capture any DDL that would be emitted for that object, without actually applying changes to the server.

SQL-DMO also has a Managed Computer object which simplifies the interface to WMI, in order to support WMI monitoring and server configuration through the SMO object interface.

뭐 아시는 분은 다 아시겠지만...

요즘 제가 DMO를 이용해 C#으로 만드는게 있는데...

요넘이 기본 .Net Framework에 포함된 library가 아니라서 제대로 된 도움말 찾기가 힘들었는데...

MSND에 정리된 link를 발견하게 되서 올립니다.

저 같은 실수를 범하지 마시라고...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sqldmo/dmoref_ob_3tlx.asp

입니다.

그럼 이만~

음... 이전 게시물을 보시면 PPT 파일이 있습니다.

강의 내용이 담긴 PPT의 내용을 중복해서 정리하면 의미가 없을 것 같으므로, PPT에 없는 내용 중 제가 적은 기억 나는 내용만 남기겠습니다.

SQL Server 초보자 이시거나 복제에 대한 경험이 없으신 분들은 일단 복제에 대한 공부를 간략하게 보시고, PPT를 보신 후 참고 하시는 것이 좋을 것 같습니다.

- 복제 시 character set에 대한 고려 : 게시자와 구독자 사이의 character set 불일치로 인한 복제 오류가 발생 할 수도 있다.

- 테이블 게시를 중지하면 timestamp 컬럼을 제거할 수 있다. (자동으로 제거되지는 않는다.)

- 병합 복제 시 기본적으로 게시자의 데이터가 구독자의 데이터에 우선한다. : 두 서버가 연결되어 있지 않은 상태에서 양쪽에서 모두 데이터를 수정할 경우, 게시자의 변경을 우선하여 update 된다.

- 스냅샷 복제 시 한 게시가 모두 복제되기 전까지 계속 s-lock(shared lock)을 걸게 되므로, insert와 update 시 문제가 발생할 수 있다. 그러므로 게시를 작은 단위로 나눌 필요도 있다.

- 복제의 부하는 7%이하라고 보여짐(완전히 주관적인 하성희 강사님의 의견 - 여러가지 상황에 따라 많이 다를 수 있습니다.)

- 복제 해제 시 순서대로 정확히 되지 않으면 해제가 되지 않아 재 성성도 안되는 경우가 있음 주의할 것

- 복제가 멈출 경우 게시자의 Transaction Log를 지울 수가 없으므로 이 점에 유의

- 복제 시 대부분 배포 에이전트쪽에서 문제가 많이 발생한다.

- 네트웍 등의 임시적 오류의 경우 Agent의 재시작만으로 문제가 해결되는 경우가 있다.

- 오류는 없는 데, 복제가 지연되는 경우 -> 구독자나 배포자의 성능에 문제가 있다.

경험담

- 배포자의 성능이 중요하다. (실제로 배포자의 H/W를 upgrade해서 성능향상의 효과를 본 적이 있다.)

- Insert나 Update 시 복제 지연 현상이 발생했었는데... 원인은 구독자의 서버 튜닝이 잘 안되어 있는 것이 원인이었음. 즉 구독자의 서버 튜닝도 중요하다.

윈도우 서비스 프로젝트를 배포 프로젝트로 만드는데, 서비스 등록까지 자동으로 되야 하는데 하는 방법을 Devpia에서 찾아보니 바로 나와있더군요.

내용은... 매우 간단~

------------------------------

간단합니다. 윈도우 서비스를 배포프로젝트로 만드시면 됩니다.

일단 설치 프로젝트를 만드신후

솔루션 탐색기를 보시면 조그마한 아이콘 7개가 있습니다.

거기서 첫번째 파일시스템 편집기->제일 왼쪽 화면에서 응용프로그램 폴더->마우스 오른쪽->추가

->프로젝트 출력->인스톨을 원하는 프로젝트를 선택하신후->기본출력->다시 조그만 아이콘에서 5번째

사용자 지정작업 편집기선택->거기보시면(설치,커밋,설치제거등4개가 있습니다) 각각을 선택하시구 마우스 오른쪽

버튼을 누르면 사용자지정작업추가가 있습니다.거기서 응용프로그램 출력에 보시면 (프로젝트이름)의기본출력(활성)이라고 있습니다.

그걸 4개 모두 지정해 주시고 빌드하시면 됩니다.

그럼 그럼 설치 프로그램이 생성됩니다.

설치하시면 윈도우서비스가 자동으로 등록됩니다.

하지만 처음에는 윈도우서비스로 가셔서 시작을 해주시던지 아니면 리부팅을 해줘야 서비스가 시작됩니다.

구럼 ^^;

시간이되면 그림을 올려보죠~

아주 간단하다...

System.Web.Mail.SmtpMail.Send("n-cash.net", "goodfeel@test.com", "test", "test");
System.Diagnostics.Process.Start("iisreset.exe");

* Duplicated Code (중복된 코드)

  - 한 클래스의 서로 다른 두 메소드 안에 같은 코드가 있는 경우 : Extract Method

  - 동일한 수퍼클래스를 갖는 두 서브클래스에서 같은 코드가 나타나는 경우 : Extract Method, Pull Up Method, Form Template Method, Substitute Algorithm

  - 관계가 없는 두 클래스에서 중복된 코드가 있는 경우 : Extract Class

* Long Method (긴 메소드)

  - 주석이 있는 부분 : Extract Method

  - 조건문과 루프가 있는 경우 : Decompose Conditional

* Large Class (거대한 클래스)

  - 많은 변수가 있는 경우 : Extract Class

  - 클래스가 모든 인스턴스 변수를 사용하지 않는 경우 : Extract Class, Extract Subclass

  - 코드가 많은 클래스 : Extract Class, Extract Subclass

  - GUI 클래스 인 경우 : Duplicate Observed Data

* Long Parameter List (긴 파라미터 리스트)

  - 객체에 요청하여 파라미터의 데이터를 얻을 수 있는 경우 : Replace Parameter with Method

  - 한 객체로부터 주워 모은 데이터 뭉치를 그 객체 자체로 바꿀 수 있는 경우 : Perserve Whole Object

  - 객체와 관계 없는 여러 개의 데이터 아이템이 있는 경우 : Introduce Parameter Object

  - 파라미터 리스트가 지나치게 길거나 자주 변경되는 경우 : 종속성 구조(dependency structure)를 생각해 볼 필요가 있다

* Divergent Change (확산적 변경) : 한 클래스가 다른 이유로 인해 다른 방법으로 자주 변경되는 경우

  - Extract Class

* Shotgun Surgery (산탄총 수술) : 변경을 할 때마다 많은 클래스를 조금씩 수정해야 하는 경우

- Move Method, Move Field

- 기존의 클래스 중에서 메소드나 필드가 옮겨갈 적절한 후보가 없다면 새로 하나를 만들어라

- Inline Class

* Feature Envy (기능에 대한 욕심)

- 어떤 값을 계산하기 위해 다른 객체에 있는 여러 개의 get 메소드를 호출하는 경우 : Move Method

- 메소드의 특정 부분만 해당하는 경우 : Extract Method, Move Method

* Data Clump (데이터 덩어리)

- 함께 몰려다니는 데이터의 무리 : Extract Class, Introduce Parameter Object, Preserve Whole Object

* Primitive Obsession (기본 타입에 대한 강박관념)

* Switch statement (Switch 문)

* Parallel Inheritance Hierarchies (평행 상속 구조)

* Lazy Class (게으른 클래스)

* Speculative Generality (추측성 일반화)

* Temporary Field (임시 필드)

* Message Chains (메세지 체인)

* Middle Man (미들 맨)

* Inappropriate Intimacy (부적절한 친밀)

* Alternative Classes with Different Interface (다른 인터페이스를 가진 대체 클래스)

* Imcomplete Library Class (불완전한 라이브러리 클래스)

* Data Class (데이터 클래스)

* Refused Bequest (거부된 유산)

* Comments (주석)

내일 이어서...

한글판 Refactoring 책을 사서 읽고 있다.

중간 중간 기억할 만한 내용을 적어놓으려고 한다.

언제 리팩토링을 해야 하는가?

- 기능을 추가할 때 리팩토링을 하라.

- 버그를 수정해야 할 때 리팩토링을 하라.

- 코드 검토(code review)를 할 때 리팩토링을 하라.

언제 리팩토링을 하지 말아야 하는가?

- 코드를 처음부터 다시 작성해야 할 때.

- 마감일에 아주 가까울 때.

쩝...

이런게 있는지 오늘 알았다 --;;

올만에 머리 썼다.

알고보면 별것도 아닌데... 분명히 대학때 배웠을텐데... 네트워크 쪽을 등한시 한 내 잘못이려니...

시스템의 내부적인 데이터 표현인데...

크게 Big-Endian과 Little-Endian이 있다.

0x12345678이라는 32비트 값을 표현했을 떄,

Big-Endian    : 0x12 0x34 0x56 0x78

Little-Endian  : 0x78 0x56 0x34 0x12

이다.

시스템이 내부적으로 데이터를 처리하는데 있어서 Big-Endian 방식을 쓰느냐, Little-Endian 방식을 쓰느냐는 시스템의 CPU에 따라 달라진다.

이를 '호스트 바이트 순서 (Host Byte Ordering)'라고 하는데 문제는 호스트 바이트 순서가 일정치 않다는 것이다.

Motorola 68000 계열이 주로 Big-Endian 방식을 쓰고 있고, 가장 많이 사용되는 Inter X86 계열은 Little-Endian 방식을 쓰고 있다.

이러한 문제 때문에 네트워크를 통해 데이터를 전송할 때는 통일된 방식을 이용해서 데티어를 전송하기로 약속을 하였는데, 이것이 바로 '네트워크 바이트 순서(Network Byte Ordering)'이다.

따라서 시스템이 Little-Endian 방식을 사용할 경우, 네트워크를 통해 데이터를 전송하기 전에 Big-Endian 방식으로 데이터를 변경해서 보내야만 하고 , 받을 때도 Little-Endian 시스템은 전송되어 오는 데이터를 역순으로 조합해야 한다.

.Net Framework의 관련 Class

IPAddress.HostToNetworkOrder()

IPAddress.NetworkToHostOrder()

휴....

.Net Framework의 클래스 라이브러리를 한번이라도 ?어 봤다면 이렇게 오래 걸리지는 안았을텐데 --;;

int를 byte array로 변환하는 것이나 byte array를 int로 변환할 일이 있었는데...

위와 같은 역할을 해 주는 class를 찾지 못해서 만들어서 사용하려고 했다.

하기 싫은 bit 연산까지 해 가며 byte array를 int로 변환하는 함수를 만들고 거꾸로 int 에서 byte array로 변환하는 함수를 만들기 전 MSDN을 좀 더 뒤져보다가

BitConverter Class를 발견하고 말았다 --;;

웅.. 여기 다 있다.

기본적인 getBytes()부터

ToChar(), ToDouble(), 물론 ToInt() ....

기쁘면서 허무하다...

.Net Framework의 관련 Class

Int -> bytes

BitConverter.GetBytes()

byte[] -> int

string -> bytes

Encoding.ASCII.GetBytes()

요즘 C# 프로그래밍에 재미를 더하고 있다...

최근에 두번째로 만든 프로그램이 있다.

특정 파일을 모니터링하다가 파일 갱신 내용으로 특정 웹페이지는 call하는 단순한 프로그램이다.

덕분에 첨으로 쓰레드도 함 써보고, 이벤트도 만들어서 함 해 보고... 재미있었다.

그런데 오늘 FileSystemWatcher의 존재에 대해 아는 강군으로부터 전해 들었다.

충격... 역시 두루두루 많이 알아야 한다는 생각이 들었다.

FileSystemWatcher이 클래스는 .Net에 있는 것으로, MSDN의 개요를 보면

----------------------------------------------------------------------------------------

파일 시스템 변경 알림을 수신하면서 디렉터리 또는 디렉터리의 파일이 변경되면 이벤트를 발생시킵니다.

FileSystemWatcher를 사용하여 지정된 디렉터리의 변경 내용을 조사합니다. 지정된 디렉터리에 있는 하위 디렉터리 및 파일의 변경 내용을 조사할 수 있습니다. 구성 요소는 로컬 컴퓨터, 네트워크 드라이브, 또는 원격 컴퓨터에 있는 파일을 조사할 수 있습니다.

참고    FileSystemWatcher 에서는 전환되거나 제거되지 않은 디스크도 조사할 수 있습니다. 타임스탬프 및 속성은 변경될 수 없으므로 FileSystemWatcher 는 CD와 DVD에 대한 이벤트는 발생시키지 않습니다. 구성 요소가 올바르게 작동되도록 하려면 원격 컴퓨터에 이러한 플랫폼 중 하나가 설치되어 있어야 합니다. 하지만 Windows NT 4.0 컴퓨터에서 원격 Windows NT 4.0 컴퓨터를 조사할 수는 없습니다.

 

----------------------------------------------------------------------------------------

라고 나와있다.

이 클래스를 이용하면 이벤트 수신만으로 쓰레드 없이 내가 한 작업을 할 수 있는 것이다.

함 써보고 사용 내용을 올려 볼란다.

좋은 사이트 정보 하나

소개글입니다.

Microsoft patterns & practices guides contain specific recommendations illustrating how to design, build, deploy, and operate architecturally sound solutions to challenging business and technical scenarios. They offer deep technical guidance based on real-world experience that goes far beyond white papers to help enterprise IT professionals, information workers, and developers quickly deliver sound solutions.

http://www.microsoft.com/resources/practices/default.asp

여러 줄 주석화 할때

/*

*/

를 이용해도 되지만..

이클립스에서 사용하던 방식으로 블럭 지정한 줄 앞에 모두 //를 붙여주는 단축키가 있습니다.

Ctrl + K + C  : 주석 붙이기

Ctrl + K + U  : 주석 해제

.Net 환경에서의 TDD에 관한 글입니다.

Unit Test와 .Net에서 사용 가능한 Mock Object의 설명과 실제 사용법까지 잘 나와 있는거 같아서 Link 합니다.

http://www.peterprovost.org/wiki/ow.asp?Test-Driven_Development_In_.NET

목차 입니다.

혹시 페이지가 없어질까봐 페이지 전문을 파일로 첨부합니다.

참고로 첨부 파일 중 Zip 파일은 .Net용 MockObject입니다.

위 첨부 파일명을 눌러도 창에서 글이 뜹니다.

음... 글 쓰다 키를 잘못 눌러서 날렸네요 --;;

다시 쓰려니 정말 귀찮지만...

csUnit은 Visual Stdio .Net에서 Unit Test를 하기 위한 Add-in software입니다. 자세한 소개는 아래 post를 참고하시구요..

http://blog.naver.com/goodfeel/80000706176

자 그럼 csUnit의 간단한 사용법 먼저 보시죠.

일단 csUnit을 다운 받은 후 설치 하고나서 Visual Stdio(이하 VS) .Net을 실행합니다.

그 다음 '새 프로젝트' 버튼을 누르면 아래와 같이 보입니다. 뭔가 바뀐게 있죠?

예.. 'csUnit Test library'라는 템플릿이 하나 추가 되어 있습니다.

아래 그림과 같이 프로젝트가 만들어 지고 'TestFixture1.cs'라는 샘플 코드가 자동 작성 됩니다.

그 Sample코드를 간단히 테스트 해 보죠.

기사는 2003년 11월에 올라 왔는데...

오늘 알았네요 --;;

VS 다음 버젼에서는 IDE 차원에서 Refactoring을 지원한다는군요.

The C# Whidbey IDE now includes refactoring support. Refactoring enables developers to automate many of the common tasks when restructuring code. For more information on refactoring, please visit http://www.refactoring.com/. Using the built-in refactoring support, developers can, for example, use the rename refactoring to automate the process of renaming a variable in source code.

The refactorings currently available in the Whidbey Technical Preview are:

• Extract Method
• Rename
• Extract Interface
• Encapsulate Field
• Change Method Signature
• Replace Arraylist

기사 원본입니다.

http://msdn.microsoft.com/vcsharp/default.aspx?pull=/library/en-us/dv_vstechart/html/whidbey_csharp_preview.asp

쩝... 계속 관련 자료 찾다가.. 우연히 Unit Testing 도구를 찾았네요.

이건 공짜~~

여깁니다.

http://www.csunit.org/index.php

다운 받고 있는데...

해 보고 잘 되면 설명도 올리던지 하죠.

그 홈페이지의 tutorials에 소스가 틀린  것도 있고... CUnit이 업데이트 됐는데, 내용이 update 안된 것들도 있긴 하지만... 음.. 잘 되네요...

오랫만에 다시 해 보니 재미있네요..

회사 컴 상태가 안좋아 화면 capture가 안되는 관계로... 노트북에 설치해서 화면 캡쳐까지 해서 사용법을 올리겠습니다.

C# 코딩하면서 편하게 Refactoring을 할 수 있는 방법이 없는지 인터넷의 세계를 항해하다 발견한 좋은 개인 Blog입니다.

한 1시간 돌아댕이면서 찾은게 이넘 찾은거 중 일부 밖에 안되네요...

참고하세요. 죄다 상용이네요...

----------------------------

출처 : http://bbs.python.or.kr/viewtopic.php?t=19659

파이썬 코드의 형식에는 수 많은 방식이 있다. 이런 자유를 남용하여 읽기 어렵게 만들고 그리하여 유지보수하기가 힘들게 코드를 작성하는 프로그래머가 많다. 적절하게 코드를 포맷하는 방법에는 여러가기 있겠지만, 여기에서는 실제로 사용할 때 쓸모가 있을 만한 가이드라인을 제공한다. 맹목적으로 따를 필요는 없지만, 어설픈 형식에는 확실하게 어깃장을 놓아볼 생각이다. 이 가이드라인중 일부는 크게 쓸모가 없어 보일 수도 있지만, 코드를 읽어 보면, 확실하게 그 차이를 느낄 수 있을 것이다.

다음에서, 각 항목은 설명다음에 그에 관련된 코드가 따른다. 이 코드로 문제를 지적하면서 코드를 교정하겠다. 항목에 코드를 짝짓는 일은 여러분의 책임이다. 모쪼록 이렇게 해서 재미있게 이 스타일 가이드를 읽기를 바란다:-) 일반적으로, 한 섹션에서 앞의 항목은 뒤의 항목보다 더 중요하며 그리고 더 자주 일어나는 에러를 나타낸다.

또, 가장 단순한 스타일의 실수를 잡는 것을 돕기 위하여 자동화된 스타일 점검기 프로그램을 제공한다. 이 프로그램은 에러 모두를 잡아내는 것은 아니지만, 일반적인 에러들을 많이 잡아낸다. 코드를 제출하려면 먼저 스타일 점검기에 그 코드를 넣어 테스트해 볼 필요가 있을 것이다; 실패하면, (스타일 점검기에 버그가 있다는 것을 확신시켜 주지 못하는 한, 물론 그럴 수 있다) 평가 대상이 되지 못한다. 파이썬 스타일 점검기는 (물론) 파이썬으로 작성되었다;-). 먼저 내려 받은 다음, "~/bin" 디렉토리에 넣고 나서 (디렉토리를 하나 만들고 탐색 경로에 넣어두면 된다) 다음과 같이 하자:

    chmod +x ~/bin/python_style_check

    python_style_check foo.py

    % python_style_check *.py

일반적으로 많이 저지르는 스타일 실수

• TABS*   코드에 탭 문자를 사용한다.
• OPERATOR_SPACE*   연산자 양쪽에 공간을 하나씩 두지 않는다.
• COMMA_SPACE*   쉼표 뒤에 공간을 두지 않는다.
• LINE_LENGTH*   78 문자가 넘는 줄을 작성한다.
• USAGE_STMT   사용 설명이 빠졌거나 부적절하다.
• BLANK_LINES   함수나 프로그램에 너무 많은 또는 너무 적은 빈 줄을 사용한다.
• COMMENTS_FULL_SENTENCES   불완전한 문장으로 주석을 작성한다.
• COMMENTS_GRAMMATICAL   문법적으로 옳지 않거나 철자가 바르지 못한 주석을 작성한다.
• COMMENT_SPACE*   열림-주석 심볼 "/*" 뒤에 닫힘-주석 심볼 "*/" 앞에 공간을 하나씩 두지 않는다.
• DOCSTRINGS   함수, 클래스, 혹은 모듈의 머리부에 적절한 문서화문자열 주석을 작성하지 않는다.
• EXCEPTIONS_CATCH_ALL   일망타진(catch-all) 예외 처리를 사용한다.

스타일 실수의 범주

일반

• [TABS]

  절대로 탭 문자(ascii 0x9)는 사용하지 말자! 사람마다 탭 설정을 다르게 사용한다. 너비가 2인 탭으로 잘 작동하는 듯 보이는 코드라도 너비가 8인 탭에서는 문제가 된다. (추천해 마지 않는) 이맥스를 사용한다면, 다음 줄들을 .emacs 파일에 넣어두자:

      ;; Load python mode.  The path will depend on the installation.    (load-file "/home/cs11/emacs/python-mode.el")    ;; Make files that end in .py automatically go into python mode.    ;; If your file doesn't end in ".py" then you'll have to do    ;; "M-x python-mode" manually after you load up the file.    (append '(("\\.py\\'" . python-mode)) auto-mode-alist)    ;; Set up initialization parameters for python mode:    (setq python-mode-hook          '(lambda () (progn                        (set-variable 'py-indent-offset 4)                        (set-variable 'py-smart-indentation nil)                        (set-variable 'indent-tabs-mode nil) )))

  이맥스에서 파이썬 코드를 편집하면서 탭 키를 치면, 자동으로 그 코드를 그 줄에서 합리적인 위치까지 들여쓰기 해 준다. 앞의 코드를 (이 코드는 emacs-lisp 코드이지만, 신경쓰지 말것) .emacs 파일 안에 넣어 두면, 탭 키를 치더라도 실제로 코드에 탭 문자가 들어가는 대신에, 그냥 네 개의 공간을 넣는다.

• [OPERATOR_SPACE]

  언제나 다음 연산자들 주위에는 각 양쪽에 공간을 하나 두자: 할당 연산자 (=, +=, 등등), 비교 연산자 (==, <, >, !=, <>, <=, >=, in, not in, is, is not), 불리언 연산자 (and, or, not), 그리고 산술 연산자. 예제:

  i = j + 1               # 불가 i=j+1        submitted += 1          # 불가 submitted+=1        x = x * 2 - 1           # 불가 x=x*2-1        hypot2 = x * x + y * y  # 불가 hypot2=x*x+y*y        c = (a + b) * (a - b)   # 불가 c=(a+b)*(a-b)

  어떤 사람들은 * 또는 / 양쪽에 공간을 두지 않는 편을 더 좋아하지만, + 그리고 -에는 우선순위에 대한 힌트로서 공간을 두기를 좋아한다. 그렇지만 이는 권장할 수 없다. 그렇지만, 간단한 증/감 연산에 대한 배열 첨자에서는 양쪽에 공간을 생략해도 좋다:

      b = a[i-1]

  불행하게도 현재 버전의 스타일 점검기는 무조건 이에 표식을 한다.

• [COMMA_SPACE]

  쉼표 다음에는 언제나 공간을 하나 두자.

• [LINE_LENGTH]

  주변에는 여전히 80개의 문자로 제한되는 장치들이 많다 (특히 프린터). 그런 장치에 대하여 기본 줄바꿈 값은 보기에 않 좋다. 그러므로, 줄들을 모두 78 자까지 제한하자.

  긴 줄을 감싸는 유력한 방법은 파이썬이 활괄호, 각괄호, 반괄호 안에서는 묵시적으로 줄이 연속되어 있다고 간주하는 점을 이용하는 것이다. 필요하다면, 표현식 주위에 괄호를 하나 더 덧붙여도 좋지만, 역사선을 이용하는 것이 더 보기 좋은 경우도 있다. 반드시 연속된 줄을 적절하게 들여쓰기 하자. 예제 약간:

      class Rectangle(Blob):        def __init__(self, width, height,                     color='black', emphasis=None, highlight=0):            if width == 0 and height == 0 \               and color == 'red' and emphasis == 'strong' \               or highlight > 100:                raise ValueError, "sorry, you lose"            if width == 0 and height == 0 and (color == 'red' \                                               or emphasis is None):                raise ValueError, "I don't think so"            Blob.__init__(self, width, height,                          color, emphasis, highlight)

  어떤 경우에는, 명시적인 줄 연속 문자가 불필요한 경우가 있다. 잘 모르겠으면, 어쨌거나 사용하자. 또, 기다란 불리언 표현식에는 (a and b and c...) "and" 또는 "or"를 줄의 끝이 아니라 앞에다 두자; 이렇게 하면 표현식이 앞의 줄에서 계속된다는 사실을 확실히 알 수 있다.

• [USAGE_STMT]

  프로그램이 올바르지 않은 인자로 호출되면, 그 사실을 탐지해서 터미날에 사용법을 인쇄해 주어야 한다. 사용 방법에는 반드시 그 프로그램의 이름이 들어가야 한다. 가장 쉽게 하는 방법은 sys.argv[0]를 이용하는 것이다. 즉

      import sys, re    # 완전한 프로그램의 경로이름을 벗겨내고 프로그램 이름만 남긴다.    prog_name = re.sub(".*/", "", sys.argv[0])    usage = "usage: %s input_filename output_filename" % prog_name    if len(sys.argv) != 2:       print usage       sys.exit(1)

  주목할 것은 인자들이 연상작용을 돕는 이름이 있다는 것이다. 사용법 메시지가 아주 길면, 문서화문자열 안에 넣자 (아래 참조).

• [BLANK_LINES]

  최고-수준의 함수와 클래스 정의는 최소한 두 개의 빈 줄로 가르자. 클래스 안에서 메쏘드 정의를 가르는 것도 역시 빈 줄 두개로 가른다. 그러나 어떤 경우에는 빈 줄 한개도 괜찮다. 관련 함수를 모아 놓은 그룹이라면 빈 줄을 더 사용하여도 좋다 (그러나 너무 지나치면 안된다). 또 주석을 두어 함수의 그룹을 갈라도 좋다. 예.

      # 다음 함수들은 위젯 클래스를 위하여 인터넷 접근을 제공한다.

  정말로 중요한 섹션이라면, 또는 클래스 머리부라면, 다음과 같이 하자:

      #    # 이 클래스 위젯이 구현하는 객체는    # 갖가지 종류의 일들을 할 수 있다.    #

  즉. 즉 머리부의 윗쪽과 아래쪽에 빈 주석 줄 하나씩을 두자.

  기다란 함수나, 또는 함수 안에서 섹션이 길다면, 주석을 함수/블록의 끝에다 다른 것도 좋은 생각이다, 예.

      def foobar(x, y, z):        # 다음에 코드가 2000 줄 따른다...        return 1    # foobar 끝	

  비슷하게, "# end if", "# end while", 등등을 두어도 좋다. 더 좋은 해결책은 이것이 필요하지 않도록 가능하면 함수와 블록을 짧게 유지하는 것이다.

  함수에서 논리적 구획을 나타내려면 빈 줄들을 사용하자. 또한 각 if/while/for 서술문 앞에다 빈 줄들을 두어서 그를 둘러싼 코드와 논리적으로 구별하기를 즐기는데, 경험상 이렇게 하면 코드가 더 읽기 쉽다.

  코드에서 서로다른 구역을 분별할 필요가 확실하지 않는 한 코드 구역 사이에 너무 많은 빈줄(> 2)을 놓지 말자.

• [INDENT_CONSISTENT]

  들여쓰기 수준은 일관성이 있어야 한다. 한 수준 들여쓰기에 4개의 공간을 선호한다.

• [MAGIC_NUMBER]

  둘러싼 코드와 별 관련이 없는 기다란 숫자를 파일에 넣는 것을 피하자. 이는 "마법의 수(magic number)"라고 알려져 있다 (역주 : 물리학 용어에서 유래, 양성자의 수 또는 중성자의 수가 미리 정해진 어떤 값을 가지면 원자핵이 특별히 안정된다. 그렇지만 처음 관찰되었을 때는 왜 그런지 잘 설명할 수가 없어서 그런 수를 마법의 수(magic number) 라고 불렀다. 마법의 수를 가지면 존재 확률이 높아짐을 비유해서, 각종 프로토콜에서 서로 간에 신분을 확인하는 숫자를 마법의 수라고 일컫는다.) 대신에 그 마법의 수를 파일의 위에다 정의해 두자.

• [USELESS_CODE]

  아무 기능이나 효과도 없는 코드를 넣지 말자. 그것이 디버깅 코드라면, 확실하게 그렇다고 표식을 해 두어야 한다.

• [STMTS_ON_LINE]

  한 줄에 여러 서술문을 두지 말자. 아주 간단한 서술문이라고 할지라도 안된다. 그저 혼란스럽고 읽기가 어렵게 만들 뿐이다. 비슷하게, 다음도 별로 마음에 안든다:

      if not line: break

  그 보다 다음을 더 선호한다:

      if not line:        break

  명심하자: 새줄문자(newlines)에는 세금이 없다. 한 줄에다가 억지로 많이 구겨 넣으려고 하지 말자.

• [BAD WHITESPACE]

  다음의 장소에는 공백(whitespace)을 사용하지 말자:

  • 활괄호, 각괄호, 또는 반괄호 바로 안쪽에서, 다음과 같이:

        spam( ham[ 1 ], { eggs: 2 } )

    언제나 다음과 같이 작성하자:

        spam(ham[1], {eggs: 2})

  • 쌍점, 쌍반점, 또는 쉼표 바로 앞에서, 다음과 같이:

        if x == 4 :        print x , y        x , y = y , x

    언제나 다음과 같이 작성하자:

        if x == 4:        print x, y        x, y = y, x

  • 함수 호출의 인자 목록을 시작하는 여는 괄호 바로 앞에서, 다음과 같이

        spam (1)

    언제나 다음과 같이 작성하자

        spam(1)

  • 지표화나 조각썰기를 시작하는 여는 괄호 바로 앞에서, 다음과 같이:

        dict ['key'] = list [index]

    언제나 다음과 같이 작성하자

        dict['key'] = list[index].

  • 다른 것과 줄을 맞추기 위해 할당 (또는 다른) 연산자 주위에 과도한 양의 공간, 예를 들어:

        x             = 1    y             = 2    long_variable = 3

    최고로 좋은 규칙: 연산자를 8개 또는 9개의 공간을 두고 이동해야 한다면, 시간을 낭비하지 말자. 그렇지 않으면, 정렬하자. 예., 다음은:

        x = 1    foo = 2    fudge = 5

    다음과 같이 바꾸자.

        x     = 1    foo   = 2    fudge = 5

    그러나 다음은

        x = 1    y = 2    this_variable_name_is_really_long = 3

    그대로 두자. 이는 스스로 내려야 하는 결단(judgment call)의 문제이다.

• [KEYWORD_SPACES]

  '='가 키워드 인수나 기본 매개변수 값을 나타내는데 사용되면 '=' 주위에 공간을 사용하지 말자. 예를 들면:

      def complex(real, imag=0.0):        return magic(r=real, i=imag)

• [PRECEDENCE]

  모든 경우에 덧셈/뺄셈과 할당 서술문 보다 곱셈/나눗셈이 우선순위가 있음을 괄호로 둘러 연산자 우선순위를 나타내자.

• [IMPORT]

  일반적으로, "from X import *"로 형태로 사용하는 것을 피하자; 다음과 같이 하든가:

      from X import Y  # 많이 사용되는 함수만 하나 수입

  또는 다음과 같이 하자:

      import X # 사용할 모듈에서 수 많은 함수가 필요할 때.

  또, 클래스나 함수 안에서 "import X"나 "from X import Y"를 사용하지 말자. 꼭 그렇게 사용해야 할 경우를 보지 못했고, 그렇게 하는 것은 혼란만 초래할 뿐이다. 모든 수입 서술문은 모듈의 최상위 수준에 그리고 파일의 최상단에 두자. 그렇게 해 두어야, 어디에서 찾아 보아야 할지 알 수 있다. 어떻게 형식화할지는 자신의 자유이다

      import X, Y, Z

  또는

      import X    import Y    import Z

  보통 한 번 쓰고 버릴 스크립트에는 앞의 형식을 커다란 프로젝트에는 뒤의 형식을 사용하는 경향이 있다.

주석

• [COMMENTS_FULL_SENTENCES]

  주석이 구이거나 문장이라면, 소문자로 시작하는 식별자가 아닌 한 첫 단어는 반드시 대문자여야 한다 (식별자의 격을 절대로 바꾸지 말 것!). 되도록 완벽한 문장이면 더 좋다. 마침표 뒤에는 공간을 두 개 사용해야 한다. 이상적으로, 식별자를 가리키려면 따옴표를 두르자, 예.

      # 변수 'nitems'은 스택에 있는 항목의 개수를 나타낸다.

  주석이 아주 짧다면, 완전한 문장이 될 필요가 없으며, 또는 마침표로 끝날 필요가 없다 예.

      i = 1  # 회돌이 지표

  이는 이른바 "인라인 주석(inline comment)"이라고 부른다. 무언가를 기술할 때만 이를 사용하자. 즉, 위의 코드 조각에서 "변수 'i'는 회돌이 지표를 나타낸다"와 같이 말할 때만 사용하자.

• [COMMENT_GRAMMATICAL]

  주석은 올바르게 철자가 되어야 한다 (오타 불가) 그리고 문법적으로 옳아야 한다. 고등하고 영어 선생님처럼 굴고자 하는 것이 아니라, 철자도 틀리고 문법도 안 맞고 게다가 오타까지 있는 주석을 읽는 것은 정말로 불쾌한 일이다.

• [COMMENT_SPACE]

  여는-주석 사인 뒤에는 늘 공간을 남겨두자 예.

      # 이 주석을 읽기 쉽다.    #이 주석은 읽기 어렵다

• [COMMENT_NON_OBVIOUS]

  정황(context)으로 미루어 완전히 짐작하기 어려운 것이면 모두 주석을 달자. 특히, 사용중인 코드나 알고리즘이 꼼수적이라면 무조건 주석을 달자. 또 각 함수의 시작부에 함수가 무슨 일을 하는지 기술하는 주석을 달자. 의심스러우면, 가능한한 주석을 달자.

• [COMMENT_REDUNDANT]

  너무나 당연한 것은 다시 주석을 달면 안된다. 이는 특히 인라인 주석에 흔하다. 예제:

      x = x + 1   # x를 증가시킨다

• [COMMENT_MEANINGLESS]

  의미없는 주석은 달지 않는다 예.

      i = 1   # i

  웃지 말것; 실제로 이런 것들을 본 적이 있다.

• [COMMENTS_CONSISTENT_WITH_CODE]

  코드와 모순되는 주석은 달지 않는 만 못하다. "코드가 변경되면 언제나 최우선으로 주석을 최신으로 유지하자!"

• [COMMENT_INDENT]

  언제나 둘러싼 코드 만큼 같은 정도로 코드를 들여쓰자.

• [COMMENT_INLINE]

  편의를 위해 인라인 주석을 되도록이면 정렬하자. 다른 말로 하면, 다음과 같이 하면 안 되고:

      x = x + 1       # x에 대한 멋진 주석    y = y + 1   # y에 대한 멋진 주석

  대신에, 다음과 같이 하자:

      x = x + 1       # x에 대한 멋진 주석    y = y + 1       # y에 대한 멋진 주석

• [COMMENT_PRECEDING]

  피할 수만 있다면 앞의 코드에 적용되는 주석을 달지 말자. 현재 코드 줄이나 또는 바로 다음에 따라오는 코드 줄들을 가리키는 주석을 달려고 노력하자.

• [COMMENT_BLOCK]

  블록 주석은 일반적으로 뒤에 따르는 코드의 일부 (또는 모두)에 적용된다. 그리고 그 코드와 같은 수준으로 들여쓰기 된다. (주석 안에서 들여쓰기된 텍스트가 아닌 한) 블록 주석의 각 줄은 #와 공간 한개로 시작한다. 블록 주석 안에서 문단은 한 개의 #를 담은 줄로 갈라진다. 블록 주석은 위와 아래에 빈 줄이 있으면 아주 좋다 (또는 새로운 함수 정의의 섹션이 시작되는 곳에 위치한 블록 주석이라면 위에 두 줄 그리고 아래에 한 줄도 좋다). 한개의 #를 가진 줄 하나로 블록 주석을 시작하고 끝내면 좋다; 이는 개인적인 선호의 문제이다. 다른 말로 하면, 블록 주석은 다음과 같이 보인다:

      #    # 빈 줄 다음에 첫 줄이 온다.    #    # 각 문단은 또 빈 줄로 갈라진다,    # 그리고 끝에는 빈 줄이 하나 있다.    #

  클래스나 함수 시작 또는 파일의 상단에 놓인 블록 주석은 반드시 문서화문자열이 되어야 한다 (아래 참고).

문서화 문자열

• [DOCSTRINGS]

  모든 모듈은 일반적으로 문서화문자열이 있어야 한다. 그리고 모듈에 수출된 모든 함수와 클래스도 역시 문서화 문자열이 있어야 한다. (__init__ 구성자를 비롯하여) 공개 메쏘드 또한 문서화 문자열이 있어야 한다. 잘 모르겠으면, 문서화 문자열을 모든 함수에 덧붙이자. 그렇지 않으면, 어쨌든 함수의 목적을 나타내는 주석을 달아야 한다. 그러므로 문서화문자열을 덧붙이지 않을 까닭이 없다.

  (독립-실행 프로그램인) 스크립트의 문서화문자열은 반드시 그의 "사용방법" 메시지가 사용이 가능하여 하며, 스크립트가 그릇된 인자로 혹은 인자가 없이 호출되면 인쇄되어야 한다 (위 참고).

  일관성을 위하여, 언제나 문서화문자열 주위에는 """삼중 겹 따옴표"""를 사용하자. 이렇게 하면 문서화 문자열을 여러 줄에 걸쳐 넣을 수 있다.

함수

• [FUNCTION_DECOMPOSITION]

  주저하지 말고 함수를 적절한 곳마다 수 많은 자잘한 함수로 분해하자. 길이가 페이지를 넘어가는 함수는 작성하지 말자.

예외 처리

• [EXCEPTIONS_CATCH_ALL]

  Don't do this:

      try:        # 코드는 여기에 둔다    except: # 모든 예외를 잡는다        pass

  현재 상황에 딱맞는 에러 처리 코드를 구현할 생각이지만, 당장은 그렇게 하고 싶지 않다면, 다음과 같이 작성하자.

      try:        # 여기에 코드를 둔다    except:  # 예외를 모두 잡는다        raise  # 잡은 예외를 다시 일으킨다

  이 모듈의 코드가 늘어나면 그 때 에러를 잡아 일반적인 방식으로 처리하자. 더 좋은 방법은, 각 예외에 대하여 따로따로 이렇게 하고 그리고 나중에 이를 고치면 얻는 효과에 대하여 주석을 다는 것이다:

      try:        # 여기에 코드를 둔다    except FooError:        # 수정요망(FIXME): 나중에 적절한 에러 처리를 구현할 것.        raise FooError # 해당 예외를 다시 일으킨다

  에러를 전혀 다루고 싶지 않다면, 절대로 안에다 'try: except:' 조건을 두지 말고, 나중을 위해 주석을 붙여 두자:

      # 수정요망(FIXME): 함수 bar()가 일으키는 FooError를 잡을 것.

출처 : http://home.hanmir.com/~johnsonj/etc/CS%2011%20Python%20track%20coding%20style%20guide.htm

기본이 되는 내용이라고 할 수 있을거 같네요.

---------------------------------------------------

파이썬 스타일 지도서

Author: Guido van Rossum
translated into korean by johnsonj

XXX 서문.

바보같은 일관성은 골치거리이다.

스타일 지도서는 일관성에 관한 것이다. 이러한 스타일 지도서의 일관성은 중요하다. 프로젝트를 수행중일때는 더 중요하다. 하나의 모듈 혹은 함수안에서의 일관성은 더욱 중요하다.

그러나 대단히 중요한 것은 : 비일관적(inconsistent)이어야 할 때를 알도록 하라 -- 때때로 스타일 지도서는 단순히 적용되지 않는다. 의심스러울 경우에는, 여러분 자신이 최선의 판단을 하라. 다른 예들을 살펴보고 어떤 것이 가장 훌륭하게 보이는 지를 결정하라. 그리고 묻기를 주저 하지 마라!

차 례

• 전체보기 -- 탭, 공백, 그리고 새로운 라인을 사용하는 법.
• 주 석 -- 주석을 (그리고 문서화 문자열들을) 적절히 사용하는 법에 관하여.
• 이 름 -- 다양한 이름짓기의 관례들.

전체보기

XXX 들어가기.

들여쓰기

Emacs의 파이썬 모드의 기본값을 사용하라: 한개의 들여쓰기 레벨당 4개의 공백을.
여러분이 혼란스럽지 않도록 진짜로 오래된 코드들에 대해서는 여러분은 8개 공백의 탭을 계속 사용할 수 있다.
Emacs의 파이썬 모드는 하나의 파일에 가장 많이 사용되는 들여쓰기 수준을 자동적으로 탐지해서 들여쓰기 매개변수를 그에 맞추어 설정한다.

탭인가 공백인가?

절대로 탭과 공백을 혼용하지 마라.
파이썬에서 가장 인기 있는 들여쓰기는 공백만을 사용하는 것이다. 두번째로 인기 있는 방법은 탭만을 사용하는 것이다.
탭과 공백을 혼용하여 들여쓰기된 코드는 공백만을 단독으로 사용하여 변환되어야만 한다.(Emacs에서는, 전체 버퍼를 선택하여 ESC-x를 쳐서 탭문자들을 없애라.)

-t 옵션으로 파이썬 명령어 해석기에 요청하면, 탭과 공백을 불법적으로 혼용한 코드에 대하여 경고를 보낸다. -tt 옵션을 사용하면 이러한 경고는 에러가 된다. 이러한 옵션들을 강력히 추천한다!

라인의 최대 길이

라인당 80자 언저리로 제한된 장치들이 여전히 많이 있다. 그러한 장치들에 대하여 기본으로 지정된 자동 줄넘기기는 보기에 흉하다. 그러므로, 모든 라인을 최대 79 문자로 한정하라(Emacs는 라인을 정확히 80자 길이에서 자동 줄넘기기를 한다.)

기다란 라인을 자동으로 줄넘기기에 선호되는 방법은 괄호, 각괄호, 대괄호안에서 파이썬의 묵시적인 라인의 연속을 이용하는 것이다. 필요하다면, 표현식 주위에 여분의 괄호 한쌍을 추가할 수도 있다, 그러나 어떤 때는 백슬래쉬를 사용하는 것이 더 좋게 보일 때도 있다. 연속된 라인을 적절히 확실하게 들여쓰기하라.
Emacs의 파이썬 모드는 이것을 정확히 수행한다. 약간의 예를 들면:

class Rectangle(Blob):    def __init__(self, width, height,                 color='black', emphasis=None, highlight=0):        if width == 0 and height == 0 and \           color == 'red' and emphasis == 'strong' or \           highlight > 100:            raise ValueError, "sorry, you lose"        if width == 0 and height == 0 and (color == 'red' or                                           emphasis is None):            raise ValueError, "I don't think so"        Blob.__init__(self, widt, height,                      color, emphasis, highlight)

공백 라인들

최상위 함수와 클래스 정의는 두개의 공백 라인으로 분리하라. 한 클래스 안에서의 메쏘드 정의는 한개의 공백라인으로 분리된다. 여분의 공백라인은 관련된 함수들의 그룹들을 분리하는데 (아주 가끔) 이용되기도 한다. 공백라인은 한무리의 관련된 한라인 짜리 명령어 (예 : 일단의 비실행명령어)사이에서는 생략되기도 한다.

공백라인을 사용하어 메쏘드 정의를 가른다면, 'class'라인과 그 첫 번째 메쏘드 정의사이에 역시 하나의 공백라인을 둔다.

논리적 구별을 나타내기 위해서 함수에는 공백라인을, 아주 아껴서, 사용하라.

표현식과 서술문에서의 공백

신경쓰이는 것들

나는 다음과 같은 위치에서 공백문자를 사용하는 것을 아주 싫어한다 :

• 괄호, 각괄호 또는 대괄호 바로 안쪽 예를 들어: spam(ham[ 1 ], { eggs: 2 } ).
  이것을 항상 다음과 같이 쓴다 :spam(ham[1], {eggs: 2}).

• 컴마, 혹은 콜론, 세미콜론 바로 앞 예를 들어: if x == 4 : print x , y ; x , y = y , x.
  이것을 항상 다음과 같이 쓴다 : if x == 4: print x, y; x, y = y, x.

• 한 함수의 호출때 사용되는 인수리스트를 감싸는 왼괄호 바로 앞 예를 들어spam (1).
  이것을 항상 다음과 같이 쓴다 spam(1).

• 지표화나 썰기를 시작하는 왼괄호 바로 앞 예를 들어: dict ['key'] = list [index].
  이것을 항상 다음과 같이 쓴다 dict['key'] = list[index].

• 다른 것 들과 맞추어 정렬하기 위하여 할당(혹은 다른) 연산자의 주위에 하나 이상의 공백을 두는 것 예 :

  x             = 1y             = 2long_variable = 3

  이것을 항상 다음과 같이 쓴다

  x = 1y = 2long_variable = 3

(위의 어떤 사항에 대해서도 나와 논쟁하려고 괴롭히지 마라 -- 나는 이미 15년간이나 이 스타일에 익숙해져 왔다.)

다른 추천사항

• 이진 연산자들은 양쪽에 한개의 공백으로 항상 두룬다 : 할당(=), 비교 (==, <, >, !=, <>, <=, >=, in, not in, is, is not), 불리언값(and, or, not).
• 수학적 연산자둘레에 공백을 삽입하는 것은 여러분이 판단하라. 항상 일관성있게 이진 연산자의 양쪽에는 공백이 있어야 한다. 약간의 예를 들면 :

  i = i+1submitted = submitted + 1x = x*2 - 1hypot2 = x*x + y*yc = (a+b) * (a-b)c = (a + b) * (a - b)

• '='이 키워드 인수 혹은 기본 매변수값을 나타낼때 사용된다면 그 둘레에는 공백을 사용하지 마라.
  예를 들어 :

  def complex(real, imag=0.0):    return magic(r=real, i=imag)

주 석

코드에 배치되는 주석은 주석이 없는 것보다도 더 나쁘다. 코드가 변하면 항상 주석을 최신으로 먼저 유지하려는 노력을 하라!

주석이 구절이거나 문장이라면, 소문자로 시작하는 식별자가 아닌한 (절대로 식별자의 대소문자를 변경하지 마라!), 그것의 첫번째 단어는 반드시 대문자로 되어야 한다.

주석이 짧다면, 마지막의 구두점은 생략되는 편이 좋다. 블록 주석은 일반적으로 완전한 문장으로 이루어진 한개 혹은 그 이상의 문단들로 구성된다. 그리고 각 문장은 반드시 구두점으로 끝나야 한다.

여러분은 한 문장을 끝내는 구두점 다음에 두개의 공백을 사용할 수 있다.
영어를 쓸데처럼 언제나, 자신있게 공백을 적용하라.

영어를 사용하지 않는 나라의 파이썬 작성자들:
여러분의 언어을 사용하지 않는 사람들이 절대로 읽지 않을 것이라고 120% 확신하지 않는한, 영어로 주석을 작성하라.

블록 주석

블록 주석은 일반적으로 약간의 코드의 (또는 모두) 앞에 적용한다, 그리고 그 코드와 동일한 레벨에서 들여쓰기를 한다. 블록 주석의 각 라인은 (그것이 주석 안쪽의 들여쓰기된 텍스트가 아닌한) #와 한개의 공백으로 시작한다.
블록 주석안의 문단은 한개의 #을 포함한 공백라인으로 분리한다. 블록 주석은 위쪽 아래쪽으로 각각 한개의 공백 라인으로 둘려 싸여지는 것이 가장 좋다 (또는 새로운 함수정의 부분이 시작되는 곳에 있는 블록 주석에는 위쪽은 2개 아래는 1개의 라인이 좋다.).

라인 주석

라인 주석은 서술문과 같은 위치에 있는 주석이다. 라인 주석은 아껴서 사용해야만 한다.
라인 주석은 적어도 그 서술문으로부터 공백 2개로 분리해야 한다. 라인주석은 #와 공백한개로 시작해야만 한다.

라인 주석이 명백한 사실을 기술할때는 사실 산만스럽고 불필요하다. 이것을 사용하지 마라:

x = x+1                 # Increment x

x = x+1                 # Compensate for border

문서화 문자열

모든 모듈은 보통 문서화 문자열을 가진다, 그리고 하나의 모듈이 수출한 모든 함수와 클래스 또한 문서화 문자열을 가진다. 공용 메쏘드 (__init__구성자를 포함하여) 또한 문서화 문자열을 가져야 한다.

한 스크립트(독자적 프로그램)에서 문서화 문자열은 "사용법" 메시지로 사용가능해야 한다. "사용법"은 스크립트가 부정확한 인수 혹은 인수를 빼먹고 (혹은 "-h"옵션을 "도움"을 위해 사용하여) 호출할 때 출력된다.
그런 문서화 문자열은 스크립트의 함수와 명령어 라인 구문, 환경 변수, 그리고 파일들에 대하여 문서화를 해 주어야만 한다. 사용법 메시지는 아주 우아하게 (몇개의 화면에) 치장할수도 있다 그리고 충분하게 새로운 사용자가 명령어를 적절히 사용할수 있도록 해 주어야만 할 뿐 아니라, 정밀한 사용자를 위해서 모든 옵션들과 인수들에 대한 완전한 참조를 제공하여야 한다.

일관성을 위하여, """ 세개의 이중인용부호"""를 문서화 문자열주위에 항상 사용하라.

두가지 형태의 문서화 문자열이 있다 : 한줄짜리 그리고 여러줄 문서화 문자열.

한줄짜리 문서화 문자열

한줄짜리 문서화 문자열은 진짜로 명백한 경우에 사용한다. 실제로 한줄에 딱 맞는다. 예를 들면:

def kos_root():    """Return the pathname of the KOS root directory."""    global _kos_root    if _kos_root: return _kos_root    ...

주의사항:

• 삼중 부호는 문자열이 한 라인에 맞을 때 조차도 사용한다. 이렇게 하면 나중에 확장하기에 편하다.
• 닫기 부호는 열기 부호와 같은 라인에 위치한다. 이렇게 해야 한줄짜리에는 더 좋아 보인다.
• 문서화 문자열의 앞 혹은 뒤에는 공백라인이 없다.
• 문서화 문자열은 구두점으로 끝나는 구절이다.
  그것은 함수의 효과를 명령어로 ("Do this", "Return that")지시하는 것이지, 설명으로 지시하지는 않는다. : 예. don't write "Returns the pathname ..."

여러-줄 문서화 문자열

여러줄 문서화 문자열은 한줄 문서화 문자열과 똑 같은 요약 라인들로 구성되는데, 공백열이 하나 따르고, 다음에 더 자세한 설명이 따른다. 요약 라인은 자동적으로 인덱스를 하는 도구들에 의하여 사용되어진다;
요약라인은 한줄에 꼭 맞아야 하고 나머지 문서화 문자열들과 하나의 공백라인에 의하여 나누어진다는 사실은 중요하다.

전체 문서화 문자열은 첫 번째 라인에 있는 부호와 같은 위치에 들여쓰기 된다.( 아래의 예를 보라).
문서화 문자열의 처리 도구는 그 문서화 문자열의 첫 번째 라인 이후로 나타나는 첫 번째 비공백라인의 위치와 똑 같은 들여쓰기 위치로 두 번째 이후 라인으로부터 많은 양의 들여쓰기를 제거할 것이다. 문서화 문자열에 있는 이후의 라인들의 상대적인 들여쓰기는 유지된다.

여러줄 문서화 문자열의 가장 마지막 문단과 닫기 부호 사이에는 공백라인 하나를 삽입하기를 추천한다, 그리고 닫기 부호는 하나의 라인에 단독으로 놓기를 추천한다. 이런 식으로 , Emacs의 문단채우기 명령어가 사용될 수 있다.

나는 또한 모든 문서화 문자열(한-줄 혹은 여러-줄)앞과 뒤에는 한개의 공백라인을 두기를 권장한다.
문서화 문자열은 클래스를 문서화 하고 -- 일반적으로 말해서, 클래스의 메쏘드는 한개의 공백라인으로 각각 분리되고, 문서화 문자열은 그 첫번째 메쏘드로부터 한개의 공백 라인만큼 떨어질 필요가 있다 ; 균형을 위해, 클래스의 머리부와 문서화 문자열 사이에 한 개의 공백라인을 가지는 것을 선호한다. 함수를 문서화 하는 문서화 문자열은 함수의 몸체가 다수의 공백 라인으로 분리되어 씌여지지 않는 한, 일반적으로 이러한 요구사항을 갖지는 않는다. -- 이러한 경우에는, 문서화 문자열을 다른 섹션으로 다루고, 그것을 하나의 공백라인으로 대체하라.

하나의 모듈을 위한 문서화 문자열은 일반적으로 클래스, 예외 그리고 함수들 (그리고 다른 어떠한 객체들)에 대한 목록을 기술해야만 하는데 그것들은 각각에 대하여 한-줄 요약을 가지고, 모듈에 의하여 수출된다. (이러한 요약들은 일반적으로 객체의 문서화 문자열에 있는 요약 라인보다는 덜 상세하다.)

함수나 메쏘드를 위한 문서화 문자열은 그것의 행위를 요약해야만 하고 그것의 인수들, 반환값, 부작용, 예외상황 발생, 그리고 호출되었을 때의 제한 상황들에 대하여 문서화를 (가능하다면 모두) 해야만 한다. 선택적 인수는 명료하게 보여져야만 한다. 키워드 인수가 인터페이스의 부분인지 아닌지가 문서화 되어야 한다.

클래스를 위한 문서화 문자열은 그것의 행위를 요약하고 공용메쏘드와 실체변수들의 목록을 나열해야 한다.
만약 클래스가 하부 클래스가 된다면, 그리고 하부클래스와의 부가적인 인터페이스를 가진다면, 이러한 인터페이스는 각각 (문서화 문자열의 형태로) 나열되어져야만 한다. 클래스 구성자는 자신의 __init__메쏘드를 위하여 문서화 문자열로 문서화 되어야 한다. 각각의 메쏘드들도 자신들만의 문서화 문자열로 문서화 되어야 한다.

하나의 클래스가 또다른 클래스를 하부클래스로 가지고 그것의 행위가 거의 그 클래스로부터 상속된다면, 그것의 문서화 문자열은 이것을 언급해야만 하고, 그 차이를 요약해야만 한다.
"override" 동사를 사용하여 하부클래스의 메쏘드가 상위클래스의 메쏘드를 대체하고 그리고 그것를 호출하지 않는다는 것을 지시하라; "extend"동사를 사용하여 하부클래스의 메쏘드가 상위클래스의 메쏘드를 호출한다는 것을 (덧붙이자면 자신의 행위에) 지시하라.

실행중인 텍스트에서 대문자로 함수나 메쏘드의 인수를 언급하는 Emacs의 관례를 사용하지마라
파이썬은 대소문자를 구별하며 그리고 인수의 이름은 키워드 인수로 사용될 수 있다, 그래서 문서화 문자열은 정확한 인수의 이름을 문서화하여야 한다. 하나의 인수는 두개의 대쉬를 이름과 설명을 구분짓는데 사용하여, 각각 한 라인에 나열하는 것이 좋다. 다음과 같이:

def complex(real=0.0, imag=0.0):    """Form a complex number.    Keyword arguments:    real -- the real part (default 0.0)    imag -- the imaginary part (default 0.0)    """    if imag == 0.0 and real == 0.0: return complex_zero    ...

버젼 기록유지하기

여러분이 소스파일에 RCS 또는 CVS 표지를 가져야만 한다면, 다음과 같이 하라.

__version__ = "$Revision: 1.4 $"# $Source: /home/guido/ftp/pub/www.python.org/doc/essays/RCS/styleguide.html,v $

이 라인들은 모듈의 문서화 문자열 뒤에 포함되어져야만 하며, 다른 코드의 앞에는, 위 아래로 하나의 공백라인으로 구분해서 포함되어져야 한다.

이름짓기 관례

파이썬 라이브러리의 이름짓기 관례는 약간은 혼란스럽다, 그래서 우리는 이것을 완벽하게 일관성이 있도록 하지는 못할 것이다.-- 그럼에도 불구하고, 여기에 약간의 가이드라인이 있다.

설명적인: 이름짓기 스타일

많은 수의 서로 다른 이름짓기의 스타일이 있다. 그것들이 무엇에 사용되는지로부터 각각, 어떤 이름 짓기 스타일이 사용되었는지를 알아낼수 있도록 도와 준다. 다음의 이름짓기 스타일은 일반적으로 자주 보는 것이다:

• x (한개의 소문자)
• X (한개의 대문자)
• lowercase (소문자)
• lower_case_with_underscores (밑줄로 연결된 소문자)
• UPPERCASE (대문자)
• UPPER_CASE_WITH_UNDERSCORES (밑줄로 연결된 대문자)
• CapitalizedWords (또는 CapWords) (단어의 첫자만 대문자)
• mixedCase (첫번째 문자가 소문자이므로 CapitalizedWords 와는 다르다!)
• Capitalized_Words_With_Underscores (보기 흉하다!)

또한 짧고 유일한 접두사를 사용하여 관계된 이름들을 무리짓는 스타일도 있다. 이것은 파이썬에서 많이 사용되지는 않지만, 완벽을 위해 언급한다. 예를 들어, os.stat() 함수는 하나의 터플을 돌려주는데 그 터플의 각 항목은 전통적으로 st_mode, st_size, st_mtime 등등과 같은 이름을 가진다. X11 라이브러리는 모든 공용 함수에 대하여 이끄는 X를 사용한다. (파이썬에서, 이러한 스타일은 일반적으로 불필요하게 생각된다. 속성과 메쏘드의 이름은 객체의 이름으로 접두어가 붙고, 그리고 함수의 이름은 모듈의 이름으로 접두어가 붙기 때문이다.)

게다가, 다음의 이끄는 혹은 끌리는 밑줄문자를 사용하는, 특별한 형태가 보인다. (이것들은 일반적으로 어떠한 경우의 관례와도 결합될 수 있다.):

• _single_leading_underscore: 약한 "내부 사용" 지시자 >
  ;(예. "from M import *" 은 밑줄문자로 시작하는 객체들을 수입하지 않는다).
• single_trailing_underscore_: 파이썬의 키워드와의 충돌을 피하기 위하여 관례적으로 사용됨
  예를 들어 : Tkinter.Toplevel(master, class_="ClassName").
• __double_leading_underscore: 파이썬 1.4에서의 클래스-사적인 이름들.
• __double_leading_and_trailing_underscore__: 사용자-제어 이름영역에 존재하는 "매력적인" 객체 혹은 속성 예를들어 : __init__, __import__ or __file__.
  때때로 이것들은 사용자에 의해서 어떠한 매력적인 행위를 촉발하도록 정의된다. (예 : operator overloading);
  때때로 이것들은 하부구조에 의해서 삽입되어져 디버깅 목적 혹은 자신만의 사용을 위해 쓰여진다. 하부구조(느슨하게 정의 하여 파이썬 인터프리터와 표준 라이브러리)는 미래의 버젼에 매력적인 속성들의 목록을 추가하기로 결정할 수 있다.
  사용자 코드는 일반적으로 자기 자신만 사용하기 위하여 이런 관례를 사용하는 것을 자제해야 한다. 하부구조의 부분이 되기를 열망하는 사용자 코드라면 밑줄들 안에서 이것을 짧은 접두사와 결합할 수 있다.
  예를 들어 : __bobo_magic_attr__.

지시적인: 이름짓기 관례

모듈 이름

모듈 이름은 MixedCase 이거나 lowercase 일 수 있다. 어떤 것을 사용할지 결정하는 명료한 관례는 없다. 한개의 클래스(혹은 많은 수의 밀접하게 연관된 클래스들, 또 약간의 부가적인 지원까지)를 수출하는 모듈은 가끔 MixedCase의 형태로 이름지어지며, 모듈의 이름으로 클래스의 이름도 동일하게 짓는다(예 : 표준 StringIO 모듈). 한 무리의 함수를 수출하는 모듈은 보통 모두 lowercase의 형태로 이름지어진다.

모듈의 이름은 화일의 이름에 사상이 되고, 어떤 화일 시스템은 대소문자를 구별하고, 긴 화일 이름을 잘라버리므로, 모듈의 이름이 아주 간결하게 선택되어야 하며 단지 다른 모듈이름과 대소문자만 달라서 충돌하지 말아야 한다. -- 이것은 유닉스에서는 문제가 되지 않는다, 그러나 코드가 맥이나 윈도우로 이식되면 문제가 발생할 것이다.

새로이 떠오르는 관례가 하나 있다. C 나 C++로 씌여진 확장모듈이 더 고수준의 (예를 들어 더욱 객체 지향적인) 인터페이스를 제공하는 파이썬 모듈을 동반할 때, 파이썬의 모듈 이름은 CapWords의 형태를 가지는 반면에, C/C++ 모듈은 모두 소문자로 이름짓고 하나의 이끄는 밑줄 문자를 가진다 (예를 들어 Tkinter/_tkinter).

"패키지"들은 ("ni"모듈이 지원하는, 모듈의 집합) 일반적으로 모두 소문자의 짧은 이름을 가진다.

클래스 이름

거의 예외없이, 클래스 이름은 CapWords 관례를 사용한다. 내부적인 사용을 위한 클래스는 부가적으로 이끄는 밑줄문자 하나를 사용한다.

예외 이름

하나의 모듈이 모든 종류의 조건들을 처리하기 위하여 하나의 예외(처리)를 정의한다면, 일반적으로 그것을 "error"혹은 "Error"라고 부른다. 내가 아는 한, 내장(확장) 모듈은 "error"(예를 들어 os.error)를 사용하는 반면에, 파이썬 모듈은 일반적으로 "Error"(예를 들어 xdrlib.Error)를 사용한다.

함수 이름

하나의 모듈에 의하여 수출된 단순한 함수는 CapWords 스타일을 사용하거나 lowercase (또는lower_case_with_underscores) 형태를 사용할 수 있다.

나는 특별히 선호하는 바는 없지만, 중요한 기능(예를 들어 nstools.WorldOpen())을 제공하는 함수에는 CapWords 스타일을 사용하고, 반면에 lowercase의 스타일은 "유틸리티"함수(예를 들어 pathhack.kos_root())에 더욱 많이 사용한다고 믿고 있다.

전역 변수 이름

(이런 변수들이 하나의 모듈안에서만 사용될것이라고 가정해보자.) 관례는 수출된 함수의 관례와 거의 동일하다. "from M import *"의 형식을 통하여 사용되도록 디자인된 모듈은 하나의 밑줄문자로 자신의 전역 변수 (그리고 내부 함수와 클래스)들에 접두사를 붙여서 그들을 수출하는 것을 막아야 한다.

메쏘드 이름

음, 이야기는 함수와 거의 동일하다. ILU를 사용할 때, 여기에 좋은 관례 하나가 있다 :

ILU 인터페이스를 통하여 발표된 메쏘드에는 CapWords를 사용하라. 객체형의 구현의 일부인, 다른 클래스 혹은 함수가 접근하는 메쏘드에는 소문자를 사용하라.
하부 클래스 혹은 상위 클래스의 속성들이 전혀 충돌하지 않거나 또는 하부 클래스 하나가 실제로 접근할 필요가 있을 때 "내부" 메쏘드와 실체 변수들에는 앞에 하나의 밑줄문자를 사용하라.

오직 현재의 클래스만이 하나의 속성에 접근하는 것이 중요할 경우에는 (클래스-지역 이름, 파이썬 1.4에서는 강제적임) 앞에 두개의 밑줄문자를 사용하라. (그러나 파이썬은 충분히 많은 루프구멍이 있어서 끈질긴 사용자는 그럼에도 불구하고 예를들어, __dict__ 속성을 통하여 접근할 수 있다. 오직 ILU 혹은 파이썬의 제한된 모드만이 XXX를 할것이다.

번역기간 : 2001.07.11 - 2001.07.15
현재버전 : 수 정 요 망
번 역 자 : 전순재

한글로 일단 바꾸고 생각해 본다.
내용은 본인도 잘 모름. 혹시 오역이 있으면 게시판에 알려주시면....고치겠습니다.

출처 : http://home.hanmir.com/~johnsonj/etc/Python%20Style%20Guide.htm

MonthDayCnt는 calendar 모듈에 이미 들어있습니다.

>>> import calendar
>>> MonthDayCnt3 = lambda year, month: calendar.monthrange(year, month)[1]
>>> MonthDayCnt3(2000, 2)
29
>>> print calendar.month(2000, 2)
February 2000
Mo Tu We Th Fr Sa Su
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29
>>>

출처 : http://bbs.python.or.kr/viewtopic.php?t=14603

import urllib
import re
import string

print "="*50
print " Beta News EntGirm Download Script!"
print "="*50
num_start = 0 #시작할 그림 번호
num_end = 2666 #마지막 그림 번호
WORK_DIR = "c:\\dir\\beta" #저장할 디렉토리 c:\dir 에 저장됩니다. 그리고 파일 앞에 beta라는 이름이 붙습니다.

def saveJPG(num, jpg_name): #파일 이름을 받아서 파일을 저장하는 함수
pagename = "http://data.betanews.net/imgdb/screen_star/%s.jpg" % jpg_name #실제파일이 있는 디렉토리
print pagename
filename = WORK_DIR + jpg_name+'.jpg' #파일이름을 만들어줌
print num, filename #번호와 파일 이름을 출력해 줍니다.
aa = urllib.urlopen(pagename) #jpg에대한 정보를 가지고있는 객체를 만들어 줍니다.
try:
f1 = open(filename, "wb") #파일을 바이너리 모드로 저장함니다.
f1.write(aa.read()) #실제 주소에서 jpg파일을 읽고 씀니다.
f1.close
except:
print "error on open %s" % filename #에러가 나면 에러 출력


for num in range(num_start,num_end):
page = "http://betanews.net/screenshot/read.html?table=screen_star&page=1&num=%d&no=5022&depth=0" % num #베타뉴스는 num숫자만 바꾸어 주면 됩니다.
try: #가끔식 에러가 나서 ...
a = urllib.urlopen(page) #페이지 정보를 읽어옴..
except:
print "Time Out...."
continue
data = a.readlines()
p = re.compile('.*image=.*') #정규표현식으로 imgage가 있는 곳만 보여줍니다.
for line_one in data:
m = p.match(line_one)
if m:
tmp = string.find(line_one,'image=') #처음 발견된 곳을 정수형 값으로 돌려줍니다.
tmp_line=line_one[tmp+6:tmp+16] #파일 이름만 함수로 넘겨주기 위함 확장자 없이
saveJPG(num, tmp_line)

print "Good Day!" #모든 파일을 읽어오면 ....

출처 : http://bbs.python.or.kr/viewtopic.php?t=14659

정규식에 대해서 대충 어떤 것인지는 알고 있었지만... 실제로 사용해 보기는 첨이었다.

다른 방법을 써도 되지만 그래도 함 공부하는 셈 치고...

MSDN에 나와 있는

######################################################################

'.NET Framework 정규식'에 대한 설명

정규식은 텍스트 처리를 위한 강력하고 효과적이며 융통성 있는 방법을 제공합니다. 정규식의 광범위한 패턴 일치 표기법을 사용하면 많은 양의 텍스트를 신속히 구문 분석하여 특정 문자 패턴을 찾을 수 있고, 텍스트 부분 문자열을 추출, 편집, 바꾸기 또는 삭제하거나 추출된 문자열을 컬렉션에 추가하여 보고서를 생성할 수 있습니다. HTML 처리, 로그 파일 구문 분석, HTTP 헤더 구문 분석 등 문자열을 다루는 여러 응용 프로그램에서 정규식은 반드시 필요한 도구입니다.

Microsoft .NET Framework 정규식은 Perl과 awk의 기능과 같은 다른 정규식 구현에서 가장 많이 사용되는 기능을 포함합니다. Perl 5 정규식과 호환되도록 디자인된 .NET Framework 정규식은 오른쪽에서 왼쪽으로 일치 검사, 실행 중 컴파일 등 다른 구현에서 아직 볼 수 없는 기능들을 포함합니다.

.NET Framework 정규식 클래스는 기본 클래스 라이브러리의 일부이며, ASP.NET 및 Visual Studio .NET과 같이 공용 언어 런타임을 목적으로 하는 언어 또는 도구와 함께 사용될 수 있습니다.

######################################################################

C#에서 정규식에 관련된 Namespace는 'System.Text.RegularExpressions' 이다.

아래 URL은 정규식을 정의할 때 사용되는 요소들에 대한 설명이다.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconRegularExpressionsLanguageElements.asp

실제 정규식을 이용하는 예제는

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconregularexpressionexamples.asp

실제 사용했던 Code

    System.Text.RegularExpressions.Regex r = new System.Text.RegularExpressions.Regex("^[0-9]*$");
   
    if(!(r.IsMatch(rows[0])))
     break;

아주 간단하죠.. 제대로 된건지 모르겠지만 테스트 해보니까 잘 작동하는 거라서..

숫자로만 이루어져 있지 않으면 끝내는 코드..

몇가지 예제입니다.

예제 출처 : http://www.taeyo.net/lecture/NET_01/cassatt_05.asp

더 많은 예제와 정보가 있는 사이트 : http://www.regexlib.com

여기도 괜찮네요 : http://www.regular-expressions.info/

정규식 만들때 사용할 수 있는 Visual한 Designer~

http://www.sellsbrothers.com/tools/#regexd

혹시 잘못된게 있거나 추가 정보가 있으면 덧글 부탁합니다.

파이썬 2.3 간편 참조서입니다.

내용이 좀 길어서 포스트 형태 유지를 위해 파일을 첨부합니다.

웹으로 바로 보실 분은 http://home.hanmir.com/~johnsonj/etc/한글판PQR232EUCKRPRINT.html 입니다.

출처는 http://home.hanmir.com/~johnsonj/ 입니다.

좋은 문서들 많이 있습니다.

네이버에 카페 하나 만들었습니다.

아직 썰렁하지만, 관심있는 분들의 도움 부탁드립니다.

서로 자료와 Know-how를 공유할 수 있는 장이 되었으면 합니다.

cafe.naver.com/sqlserver

'프로필'을 누르신 후 '운영중인 카페'에서 'SQL Server 사용자모임'을 선택하시면 됩니다.

음... 실제 표준으로 제정된건 아니고, 글 쓴사람이 제안하는거 같은데...

괜찮은거 같아서...

울 회사에서도 어느 정도의 naming rule을 정해서 개발을 하고 있는데(물론 어기는 사람도 가끔 있지만 --;;) 여러모로 장점이 많은데...

이 글에는 울 회사에서 사용하지 않는 rule도 있어서 함 소개합니다.

출처 : http://www.sqlservercentral.com/columnists/sjones/codingstandardspart1.asp

-------------------------------------------------------------------------------

• Databases
  

  Each database on a server should be named using a name that is logical and applicable to the use of the database. Since third party databases often require specific names, this specification cannot give more concrete examples of naming standards. If you are building software which may be deployed on another server, you may wish to prefix the database name with some acronym signifying your company, as in example 3.

  Examples:
  

  • Sales
  • Dynamics
  • IBM_SalesAnalysis

• Backup Devices (Full Backup)
  

  Any file that contains a complete backup should be named in the following format:
  <database name>_<4 digit year><month><day><hour><minute><second>
  where all times are the time the backup was started. The extension for all full backup files should be ".bak". All items should include leading zeros for values whose size is less than the size of the maximum value, i.e. always include a 2 digit month.

  Examples:
  

  • Sales_20011015080000.bak
  • Dynamics_20010908000000.bak

• Backup Devices (Differential Backup)
  

  Any file that contains a differential backup should be named in the following format:
  <database name>_<4 digit year><month><day><hour><minute><second>
  where all times are the time the backup was started. The extension for all full backup files should be ".dif". All items should include leading zeros for values whose size is less than the size of the maximum value, i.e. always include a 2 digit month.

  Examples:
  

  • Sales_20011015083000.dif
  • Dynamics_20010908120000.dif

• Backup Devices (Transaction Log Backup)
  

  Any file that contains a transaction log backup should be named in the following format:
  <database name>_<4 digit year><month><day><hour><minute><second>
  where all times are the time the backup was started. The extension for all full backup files should be ".trn". All items should include leading zeros for values whose size is less than the size of the maximum value, i.e. always include a 2 digit month.

  Examples:
  

  • Sales_20011015081500.trn
  • Dynamics_20010908080000.trn

• Logins
  

  All login names should follow the company standards for network login names. Currently the standard is:
  <first initial>_<last name><middle initial (if needed)>

  Examples:
  

  • sjones
  • bknight

• Users
  

  All database user names should match the login name to which it is mapped. NO User accounts should be shared among multiple logins. Use roles instead.

  Examples:
  

  • sjones
  • bknight

• Roles
  

  All database roles should be named for the function of the role. This may be the name of the department or the job function.

  Examples:
  

  • Marketing
  • PurchasingAgents

• Tables
  

  All tables should be named for the function of the table. For multiple word tables, the name should be in proper case for each word. No spaces should be used in table names.

  Examples:
  

  • Orders
  • OrderLineItems

• Columns
  

  Columns used in either tables or views should follow the same naming convention as for tables. Proper case all words with no spaces inside the name.

  Examples:
  

  • OrderID
  • ProductCode
  • QuantityPurchased

• Views
  

  All view names should begin with a lower case "v" and then follow the same naming conventions as for a table. Proper case all words in the name with no internal spaces. If this is a view of a single table and contains all fields, then use "v" plus the table name.

  Examples:
  

  • vOrderDetails
  • vProduct

• Indexes
  

  All indexes should be named in the following format:
  <Table name>_<index type><index number (optional)> where the table name matches the table or view to which the index is being applied. The index types are:
  Primary Key - PK
  Clustered Index - IDX
  Nonclustered Index - NDX
  Only when there is more than one nonclustered index should the index numbering be used.

  Examples:
  

  • Orders_PK
  • Products_IDX
  • ProductDetails_NDX
  • ProductDetails_NDX2

• Triggers
  

  All triggers should contain the name of the table, an underscore followed by "tr" and the letters which represent the intention of the trigger (i for insert, u for update, d for delete). If there are more than one trigger, a numerical designation, starting with 2 should be appended to the name.

  Examples:
  

  • Customers_tri
  • Orders_triu
  • Products_trd
  • Products_trd2

• User Defined Functions (UDFs)
  

  A user defined function should prefixed by "udf_" and then a description that logically follows the function process. The description should be proper case words with no spaces.

  Examples:
  

  • udf_GetNextID
  • udf_SumOrderLines

• Defaults
  

  All defaults should be prefixed with "df_" and then some description of the default value. The description should be proper case with no spaces or underscores.

  Examples:
  

  • df_One
  • df_GetDate