มารยาทในการเขียนโปรแกรม
posted on 01 Jun 2005 16:29 by kaze in Technology
เนื่องจากเราทำงานอยู่ในบริษัทที่พัฒนาซอฟต์แวร์
แล้วซอฟต์แวร์ของบริษัท มี LOC (Lines Of code) ค่อนข้างเยอะ
แล้วที่เซ็งอย่างเห็นได้ชัด คือการเขียน code ของเดิมที่มีคนเขียนไว้
เลยสรุปใส่บลอกตัวเองไว้ เพื่อเตือนตัวเองเวลาเขียนอะไรไว้
จะได้เขียนให้เวลากลับมาอ่านจะได้ดูง่ายๆ ไม่ได้เขียนถึงการ design
แต่เขียนถึง discipline ของการเขียนโปรแกรม
1. การ include header file เห็นมามากเหมือนกัน ที่มีคนใช้
เครื่องหมาย double quote (") เช่น
#include "my_header.h"
บางคนยังไม่เคยรู้ด้วยซ้ำว่ามันต่างกันยังไงกับเครื่องหมาย
น้อยกว่า (<) และมากกว่า (>) เช่น
#include <stdio.h>
ข้อแตกต่างคือ double quote หา header จาก current directory
หรือ directory ที่เรากำหนด แต่ไม่หาใน standard library แต่ <>
จะไปหาใน standard library ด้วย เช่น ใน gcc จะใช้ option -I
gcc -Idir ...
เหตุการณ์ที่เคยเจอคือ มี file ที่ include header เยอะมากๆ
พอต้องการจะเอา header บางตัวออก ลอง find หาดูใน file
พี่ท่านเล่น include ตั้ง 3-4 ครั้ง -_-" ที่จริงมันก็ไม่ได้มีผล
ต่อซอฟต์แวร์สักเท่าไหร่ เพียงแต่มันเปลืองพื้นที่เก็บหว่ะ
แล้วเวลาเอา Baseline ของซอฟต์แวร์มาแก้ที่ ก็ไป download
จาก Head Quarter ที่อยู่ต่างประเทศ ซึ่งเปลือง Bandwidth จริงๆ
คิดประมาณว่า file .c มีสัก 10000 file แล้วมัน include ซ้ำ
ทุก file (file นึงมันต้อง include สัก 50-100 file โอกาสซ้ำเลยมี)
ซ้ำทีก็เสียพื้นที่เก็บคร่าวๆ 16 byte สมมติว่า file นึงซ้ำสัก 7 ที่
10000 file ก็เสียพื้นที่ไปแล้ว 1 MB แล้วบริษัทซอฟต์แวร์ส่วนใหญ่
ที่มี product เป็นของตัวเอง มักจะต้อง maintain หลายๆ version
วิธีแก้มันก็ง่ายนิดเดียว
include เรียงชื่อ header ตามตัวอักษรจาก A-z
ซึ่ง Editor สำหรับ Programmer ส่วนใหญ่จะมี function ในการ
sort by ascending หรือ descending ให้อยู่แล้ว
แต่ก็ดันซวยอีกประมาณว่าคนที่ทำอยู่เดิม เค้า include ไม่ครบ
เวลาสลับที่เลยเกิดปัญหาอีก เวงกำ จริงๆ -_-"
แต่ก่อนมันผ่านเพราะ file ก่อนหน้ามัน include มาให้ เช่น
a.c
#include <c.h>
#include <b.h>
...
b.h
#include <e.h>
...
c.h
#include <d.h>
...
b.h มีการอ้างถึง struct ที่อยู่ใน d.h ทำให้เมื่อเรียง header
ใน a.c ทำให้ b.h ไม่รู้จัก struct ใน d.h
2. Indentation เป็นสิ่งนึงที่ทำให้อ่าน code อ่านได้ยากหรือ
ง่าย ซึ่งตามปกติแล้วจะ ใช้ space 4 ช่อง ซึ่ง Editor มันก็
insert space แทน tab ให้เราได้ อย่าง VC++ มันก็ใส่
space 4 ช่องให้เมื่อเรากด tab
แต่ดันยังมีคนใช้ space 8 ให้เห็นอีกโว้ย T_T
นั่นยังไม่เท่าไหร่ เพราะ replace space 8 by 4 ได้สบาย
แต่มันดันมีคนใช้ space 2 อีกเนี่ย -_-"
น่าอิจฉาคนเขียน python จังเลย
3. Function prototype เคยสังเกตไหมว่า พวก function
มาตรฐานต่าง เวลาที่มี parameter ที่รับ output คืนจาก
function เค้าจะเอา parameter เหล่านั้นขึ้นก่อน เช่น
strcpy(string_output, string_input);
แต่ดันมีพวกที่ใส่มั่วๆ เอาไปใส่ข้างหลังบ้าง
ตรงกลางบ้าง -_-"
แบบว่า function ดันรับ parameter เยอะเป็น 20-30
นั่งหาทีก็นะ ตาลาย
4. Link object ที่จะ compile เป็น execute file ก็ควร
จะ link เฉพาะ file ที่ใช้ เพราะจะได้ทำให้ execute file เล็กลง
ที่ไปเจอมา ประมาณว่า file ใน directory นั้น มีเท่าไหร่
มัน link ไปหมดเอาทุก file มา compile กำจริงๆ
g++ มันเอามาหมดเลยนะ ไม่สนว่า file นั้นจะใช้หรือป่าว
5. อันนี้ สำหรับคนที่เขียน C++ แต่ยังติดนิสัย C อ่านเจอใน
The C++ Programming Language (Special Edition)
ของ Bjarne Strousstrup (Creator of C++)
สำนักพิมพ์ Addison Wesley Longman เข้าเขียนข้อแนะนำ
สำหรับ C Programmer ที่มาเขียน C++ ไว้ 5 ข้อ
#ifdef DEBUG
#define PDEBUG(fmt, ...) fprintf(stdout, fmt, ##__VA_ARGS__)
#else
#define PDEBUG(fmt, ...)
#endif
int main() {
PDEBUG("Debug message => %s\n", "Test");
return 0;
}
ถ้าการ set ลำดับไม่มีผล ควรจะเรียงตามความสัมพันธ์ และตัวอักษร
ถ้าชื่อตัวแปรความยาวไม่ต่างกันมาก
เครื่องหมายเท่ากับ (=) ควรอยู่แนวเดียวกัน
baseCurrency.setEffectiveDate(sysDate);
baseCurrency.setEndDate(lastDate);
baseCurrency.setInceptionDate(sysDate);
7. เวลา comment ใน C/C++ Java ควรจะใช้ แบบ Multi-line
/* Multi-line comment */
เพราะเวลาเขียนโปรแกรมแล้วต้องการ comment เป็นส่วนๆ
เพื่อการ debug หรือ อะไรก็แล้วแต่ Editor ส่วนใหญ่จะ
comment แบบ Single line ให้
// Single line comment
จะได้สะดวกในการหาเวลา code สัก 10000
บรรทัดจะนั่งหาก็กระไรอยู่
ไว้แค่นี้ก่อนล่ะกัน วันหลังคิดอะไรออกค่อยเขียนต่อ...
แล้วซอฟต์แวร์ของบริษัท มี LOC (Lines Of code) ค่อนข้างเยอะ
แล้วที่เซ็งอย่างเห็นได้ชัด คือการเขียน code ของเดิมที่มีคนเขียนไว้
เลยสรุปใส่บลอกตัวเองไว้ เพื่อเตือนตัวเองเวลาเขียนอะไรไว้
จะได้เขียนให้เวลากลับมาอ่านจะได้ดูง่ายๆ ไม่ได้เขียนถึงการ design
แต่เขียนถึง discipline ของการเขียนโปรแกรม
1. การ include header file เห็นมามากเหมือนกัน ที่มีคนใช้
เครื่องหมาย double quote (") เช่น
#include "my_header.h"
บางคนยังไม่เคยรู้ด้วยซ้ำว่ามันต่างกันยังไงกับเครื่องหมาย
น้อยกว่า (<) และมากกว่า (>) เช่น
#include <stdio.h>
ข้อแตกต่างคือ double quote หา header จาก current directory
หรือ directory ที่เรากำหนด แต่ไม่หาใน standard library แต่ <>
จะไปหาใน standard library ด้วย เช่น ใน gcc จะใช้ option -I
gcc -Idir ...
เหตุการณ์ที่เคยเจอคือ มี file ที่ include header เยอะมากๆ
พอต้องการจะเอา header บางตัวออก ลอง find หาดูใน file
พี่ท่านเล่น include ตั้ง 3-4 ครั้ง -_-" ที่จริงมันก็ไม่ได้มีผล
ต่อซอฟต์แวร์สักเท่าไหร่ เพียงแต่มันเปลืองพื้นที่เก็บหว่ะ
แล้วเวลาเอา Baseline ของซอฟต์แวร์มาแก้ที่ ก็ไป download
จาก Head Quarter ที่อยู่ต่างประเทศ ซึ่งเปลือง Bandwidth จริงๆ
คิดประมาณว่า file .c มีสัก 10000 file แล้วมัน include ซ้ำ
ทุก file (file นึงมันต้อง include สัก 50-100 file โอกาสซ้ำเลยมี)
ซ้ำทีก็เสียพื้นที่เก็บคร่าวๆ 16 byte สมมติว่า file นึงซ้ำสัก 7 ที่
10000 file ก็เสียพื้นที่ไปแล้ว 1 MB แล้วบริษัทซอฟต์แวร์ส่วนใหญ่
ที่มี product เป็นของตัวเอง มักจะต้อง maintain หลายๆ version
วิธีแก้มันก็ง่ายนิดเดียว
include เรียงชื่อ header ตามตัวอักษรจาก A-z
ซึ่ง Editor สำหรับ Programmer ส่วนใหญ่จะมี function ในการ
sort by ascending หรือ descending ให้อยู่แล้ว
แต่ก็ดันซวยอีกประมาณว่าคนที่ทำอยู่เดิม เค้า include ไม่ครบ
เวลาสลับที่เลยเกิดปัญหาอีก เวงกำ จริงๆ -_-"
แต่ก่อนมันผ่านเพราะ file ก่อนหน้ามัน include มาให้ เช่น
a.c
#include <c.h>
#include <b.h>
...
b.h
#include <e.h>
...
c.h
#include <d.h>
...
b.h มีการอ้างถึง struct ที่อยู่ใน d.h ทำให้เมื่อเรียง header
ใน a.c ทำให้ b.h ไม่รู้จัก struct ใน d.h
2. Indentation เป็นสิ่งนึงที่ทำให้อ่าน code อ่านได้ยากหรือ
ง่าย ซึ่งตามปกติแล้วจะ ใช้ space 4 ช่อง ซึ่ง Editor มันก็
insert space แทน tab ให้เราได้ อย่าง VC++ มันก็ใส่
space 4 ช่องให้เมื่อเรากด tab
แต่ดันยังมีคนใช้ space 8 ให้เห็นอีกโว้ย T_T
นั่นยังไม่เท่าไหร่ เพราะ replace space 8 by 4 ได้สบาย
แต่มันดันมีคนใช้ space 2 อีกเนี่ย -_-"
น่าอิจฉาคนเขียน python จังเลย
3. Function prototype เคยสังเกตไหมว่า พวก function
มาตรฐานต่าง เวลาที่มี parameter ที่รับ output คืนจาก
function เค้าจะเอา parameter เหล่านั้นขึ้นก่อน เช่น
strcpy(string_output, string_input);
แต่ดันมีพวกที่ใส่มั่วๆ เอาไปใส่ข้างหลังบ้าง
ตรงกลางบ้าง -_-"
แบบว่า function ดันรับ parameter เยอะเป็น 20-30
นั่งหาทีก็นะ ตาลาย
4. Link object ที่จะ compile เป็น execute file ก็ควร
จะ link เฉพาะ file ที่ใช้ เพราะจะได้ทำให้ execute file เล็กลง
ที่ไปเจอมา ประมาณว่า file ใน directory นั้น มีเท่าไหร่
มัน link ไปหมดเอาทุก file มา compile กำจริงๆ
g++ มันเอามาหมดเลยนะ ไม่สนว่า file นั้นจะใช้หรือป่าว
5. อันนี้ สำหรับคนที่เขียน C++ แต่ยังติดนิสัย C อ่านเจอใน
The C++ Programming Language (Special Edition)
ของ Bjarne Strousstrup (Creator of C++)
สำนักพิมพ์ Addison Wesley Longman เข้าเขียนข้อแนะนำ
สำหรับ C Programmer ที่มาเขียน C++ ไว้ 5 ข้อ
5.1 Macro ไม่มีความจำเป็นใน C++ เค้าเขียนเอาไว้ว่า
ให้ใช้ const, enum ในการกำหนดค่าคงที่, ใช้ inline
แทนการใช้ function macro, ใช้ template แทน
function ที่คล้ายกัน และใช้ namespaces เพื่อป้องกัน
การซ้ำของชื่อ แต่เราว่ามันยังมีที่ต้องใช้ก็คือ การ debug
ถ้า compile แบบ debug ให้แสดง debug message ด้วย
แต่ถ้า release ไม่ต้อง ตัวอย่าง
#include <stdio.h> ให้ใช้ const, enum ในการกำหนดค่าคงที่, ใช้ inline
แทนการใช้ function macro, ใช้ template แทน
function ที่คล้ายกัน และใช้ namespaces เพื่อป้องกัน
การซ้ำของชื่อ แต่เราว่ามันยังมีที่ต้องใช้ก็คือ การ debug
ถ้า compile แบบ debug ให้แสดง debug message ด้วย
แต่ถ้า release ไม่ต้อง ตัวอย่าง
#ifdef DEBUG
#define PDEBUG(fmt, ...) fprintf(stdout, fmt, ##__VA_ARGS__)
#else
#define PDEBUG(fmt, ...)
#endif
int main() {
PDEBUG("Debug message => %s\n", "Test");
return 0;
}
เวลา gcc -DDEBUG ... มันก็จะ print debug message ออกมา
เอ.. หรือว่า C++ มีวิธีอื่นอ่ะ -_-?
5.2 อย่าประกาศตัวแปรก่อนที่คุณจะต้องการใช้มันจริงๆ เช่น ใน for loop
for (int i = 0; i < 12; i++) {
days[i] = year.getAmountBusinessDayOfMonth(i+1);
}
5.3 อย่าใช้ malloc ให้ใช้ new operator แทน อย่าใช้ realloc ให้ใช้ vector
5.4 พยายามหลีกเลี่ยง void* สำหรับ explicit conversion type ให้ใช้ cast ในแบบ
ของ C++ (static_cast, reinterpret_cast) อันนี้รู้แค่ concept แต่ไม่เคยใช้ เพราะ
ไม่ค่อยได้ทำ explicit conversion
5.5 ใช้ array หรือ string ในรูปแบบของ C ให้น้อยที่สุด โดยการใช้ standard
library C++ string และ vector แทน
6. เวลา set ค่าตัวแปรหรือ attribute ของ class ที่ละเยอะๆเอ.. หรือว่า C++ มีวิธีอื่นอ่ะ -_-?
5.2 อย่าประกาศตัวแปรก่อนที่คุณจะต้องการใช้มันจริงๆ เช่น ใน for loop
for (int i = 0; i < 12; i++) {
days[i] = year.getAmountBusinessDayOfMonth(i+1);
}
5.3 อย่าใช้ malloc ให้ใช้ new operator แทน อย่าใช้ realloc ให้ใช้ vector
5.4 พยายามหลีกเลี่ยง void* สำหรับ explicit conversion type ให้ใช้ cast ในแบบ
ของ C++ (static_cast, reinterpret_cast) อันนี้รู้แค่ concept แต่ไม่เคยใช้ เพราะ
ไม่ค่อยได้ทำ explicit conversion
5.5 ใช้ array หรือ string ในรูปแบบของ C ให้น้อยที่สุด โดยการใช้ standard
library C++ string และ vector แทน
ถ้าการ set ลำดับไม่มีผล ควรจะเรียงตามความสัมพันธ์ และตัวอักษร
ถ้าชื่อตัวแปรความยาวไม่ต่างกันมาก
เครื่องหมายเท่ากับ (=) ควรอยู่แนวเดียวกัน
baseCurrency.setEffectiveDate(sysDate);
baseCurrency.setEndDate(lastDate);
baseCurrency.setInceptionDate(sysDate);
7. เวลา comment ใน C/C++ Java ควรจะใช้ แบบ Multi-line
/* Multi-line comment */
เพราะเวลาเขียนโปรแกรมแล้วต้องการ comment เป็นส่วนๆ
เพื่อการ debug หรือ อะไรก็แล้วแต่ Editor ส่วนใหญ่จะ
comment แบบ Single line ให้
// Single line comment
จะได้สะดวกในการหาเวลา code สัก 10000
บรรทัดจะนั่งหาก็กระไรอยู่
ไว้แค่นี้ก่อนล่ะกัน วันหลังคิดอะไรออกค่อยเขียนต่อ...
นอกนั้นก็ทำจนเป็นธรรมชาติไปแล้ว
แล้วก็เรื่อง reinterpret_cast นี่ไม่ควรใช้นะครับ มันเป็น low-level,unsafe conversion อะครับ ใช้เฉพาะ static_cast กับ dynamic_cast ก็น่าจะพอนะครับ
ไม่รู้ว่าพี่เคยเห็นหนังสือเล่มนี้รึเปล่าครับ ผมว่าเค้ารวมอะไรแปลก ๆ ไว้ดี
How Not to Program in C++: 111 Broken Programs and 3 Working Ones, or Why Does
2+2=5986
by Steve Oualline
#1 By T!D on 2005-06-01 21:42