Re: [討論] 大家對新人程式的要求？

看板Soft_Job作者 (要算命的找我)時間17年前 (2008/09/22 21:21), 編輯推噓34(34推 0噓 55→)
留言89則, 18人參與, 最新討論串12/16 (看更多)
我講一下關於coding style的部分，我認為這是一個好RD最基本的觀念 也是team work最簡單能做到的地方 舉個例好了，當前後的code都這麼寫 for(int i=0 ; i<10 ; i++) { a += 10; } 如果今天面試的人這麼寫 for(inr i=0 ; i<10 ; i++) a+=10; 我就會認定他是不懂得follow coding style的人 但如果是 for(int i =0 ; i<10 ; i++){ a+=10; } 這樣就還可以接受 有人說模組化切開就沒這個問題，但是總會有人離職 一組程式會有好幾個人碰過（我都說那是人盡可夫的程式...） 難道裡面要有四五種風格嗎？那要是被新人接到不就是要逼他走人... 新人剛進來一定會code review的，不管他工作了幾年 有人說這樣會受到約束，我倒是覺得如果約束一個人可以讓整個team更smooth 我會很樂意做這樣的事，別人不需要為你的習慣付出代價 也希望剛找工作的新鮮人能注意，個人的習慣最好能跟team的風格做個配合 ※ 引述《TonyQ (沉默是金)》之銘言： : ※ 引述《TitanSue (要算命的找我)》之銘言： : : 推 su35:要我每天去猜他的程式什麼意思 這種公司我也不願意去 把程式 09/22 00:11 : : → su35:整個都切割分開來 程式流程圖明確 不管每個人寫的風格如何 就 09/22 00:12 : : → su35:沒差了 09/22 00:13 : : 推 andymai:那原po所謂的coding style長怎樣?可以讓小弟見識一下嗎? 09/22 00:17 : : → andymai:感覺有點像把"思考模式"統一化~看到別人的code像自己寫的 09/22 00:19 : 比方說 , 像有些人會去考慮相依性問題 , : dao , model , service切得很開 , : 也就是如果你在model call dao的東西 , : 很抱歉 ,compile是會過不去的 . XD : 還有一些是命名法則跟資料夾怎麼開 ,不見得需要看到別人code像自己寫的, : 但是起碼會有一點蛛絲馬跡可尋 , 還有一些就是避免造成coding困擾的地方, : 像類別的 getter/setter 要放在class的前中後的哪一區等等 . -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.62.187.73
推
09/22 21:41, , 1F
如果面試官是愛第二種一行完成的呢= =?
09/22 21:41, 1F
推
09/22 21:55, , 2F
他有提到「前後code都這樣寫」...
09/22 21:55, 2F
推
09/22 22:01, , 3F
可是Sun的Java Convention不就是第三種寫法嗎？
09/22 22:01, 3F
→
09/22 22:04, , 4F
我在Eclipse的Code Style設定中看到的(Java Conventions
09/22 22:04, 4F
→
09/22 22:04, , 5F
[build-in])
09/22 22:04, 5F
→
09/22 22:06, , 6F
code寫的好不好看,多去看jdk的source或是apache project
09/22 22:06, 6F
→
09/22 22:06, , 7F
的src不就好了
09/22 22:06, 7F
推
09/22 22:36, , 8F
哇!嚴厲到連這個也要~不過...我個人也比較喜歡把左右大括
09/22 22:36, 8F
→
09/22 22:37, , 9F
號打出來~幹嘛省這點時間卻可能讓人debug時判斷錯誤...
09/22 22:37, 9F
推
09/22 22:43, , 10F
囧，完了。我不太喜歡太正規的寫法，我連寫 For loop
09/22 22:43, 10F
→
09/22 22:44, , 11F
都會 把 初始值 和 變動量 拆出來寫 Orz...
09/22 22:44, 11F
推
09/22 23:08, , 12F
我們也很重style.. code幾萬行 review起來真的有差
09/22 23:08, 12F
推
09/22 23:11, , 13F
不要說幾萬 幾百行 光把{}被省略的地方 邏輯搞清楚
09/22 23:11, 13F
→
09/22 23:11, , 14F
就要花很多時間了....
09/22 23:11, 14F
推
09/22 23:13, , 15F
個人不喜歡 for( int i; 這種格式，會造成重複宣告的麻煩
09/22 23:13, 15F
推
09/22 23:19, , 16F
不是喜好問題, 重點是原來程式怎麼寫就怎麼跟...
09/22 23:19, 16F
推
09/22 23:22, , 17F
在實際運算值變的地方宣告變數為什麼會是好的？ @_@?
09/22 23:22, 17F
推
09/22 23:30, , 18F
因為符合最小scope的原則....
09/22 23:30, 18F
推
09/22 23:34, , 19F
個人非常厭惡省略大跨號，因為很多小bug就是這樣來的~
09/22 23:34, 19F
推
09/22 23:35, , 20F
給樓上, 用 python 吧 XD
09/22 23:35, 20F
推
09/22 23:41, , 21F
那也要用 c99 或 c++ 才會符合啊 XD
09/22 23:41, 21F
推
09/22 23:42, , 22F
i大說的沒錯..原來程式要接著maintain,code很髒就很難搞
09/22 23:42, 22F
→
09/22 23:43, , 23F
除非你願意花時間去把該變數每個出現的地方都改名稱..
09/22 23:43, 23F
→
09/22 23:45, , 24F
ps剛講的是變數命名style.. 我甚至不喜歡i,j,m這種出現
09/22 23:45, 24F
推
09/23 00:11, , 25F
我用Eclipse當IDE，有快速鍵作code style排版
09/23 00:11, 25F
→
09/23 00:11, , 26F
所以只要把要維護的code的style弄成預設就ok
09/23 00:11, 26F
→
09/23 00:12, , 27F
但是變數命名就真的要看習慣跟經驗了
09/23 00:12, 27F
推
09/23 00:14, , 28F
code complete裡建議不要偷懶用 i,j,m 這種無意義的變數
09/23 00:14, 28F
→
09/23 00:15, , 29F
名稱,即使只是一個loop裡的臨時變數,也不要偷懶.
09/23 00:15, 29F
→
09/23 00:16, , 30F
要改正一些老傢伙或自由派的同事,還是直接搬書出來比較
09/23 00:16, 30F
→
09/23 00:18, , 31F
快,這年頭很多人在比較程式的好壞,是在於"執行速度"和"
09/23 00:18, 31F
→
09/23 00:19, , 32F
code size",可讀性,擴充性根本沒幾個人在意.
09/23 00:19, 32F
推
09/23 00:32, , 33F
哈哈, i j k m n p, 寫很久的程式設計師都會這樣用
09/23 00:32, 33F
推
09/23 00:33, , 34F
如果是小loop的loop counter，這也沒啥不好 XD
09/23 00:33, 34F
→
09/23 00:33, , 35F
而這時觀看的重點是 "命名", 而非在這些暫時變數上面 ...
09/23 00:33, 35F
推
09/23 00:35, , 36F
dummy 就是 dummy, 我反而不能接受硬要幫他們取名字....
09/23 00:35, 36F
→
09/23 00:35, , 37F
不過, 這種命名反而不會應用到低階語言上面就是
09/23 00:35, 37F
→
09/23 00:35, , 38F
int i_this_is_a_dummy_index_variable;
09/23 00:35, 38F
→
09/23 00:36, , 39F
因為低階語言寫作, 能不用到變數就不要用, 存取暫存器速度快
09/23 00:36, 39F
→
09/23 00:37, , 40F
ledia.. int *p_this_is_a_temporary_pointer XD
09/23 00:37, 40F
→
09/23 00:38, , 41F
int reportGenLoopCounterInner 雙重迴圈還送outer喔
09/23 00:38, 41F
推
09/23 00:42, , 42F
迴圈的計數變數用 i, j 怎麼會無意義? 難道要寫 loopCounter?
09/23 00:42, 42F
→
09/23 00:42, , 43F
這樣才是多此一舉吧
09/23 00:42, 43F
→
09/23 00:44, , 44F
對了, 這種命名, 小寫的 L 會跳過, 因為會混淆 :)
09/23 00:44, 44F
推
09/23 00:56, , 45F
dummy是指無意義,只是為了語法才留著的變數,和i並不相同
09/23 00:56, 45F
→
09/23 00:58, , 46F
仔細想一下,每個for配合i的迴圈,其實當中的i都會有它的
09/23 00:58, 46F
→
09/23 00:59, , 47F
意義存在,例如,把每個月的收入加總, for(i=1;i<=12;i++)
09/23 00:59, 47F
→
09/23 01:00, , 48F
i其實就是month,那為何要寫i,不寫month? 剛開始我也覺得
09/23 01:00, 48F
→
09/23 01:01, , 49F
CC要求i不要出現太極端,現在用久了,才覺得,真的過去的習
09/23 01:01, 49F
→
09/23 01:01, , 50F
慣,才會覺得i的出現很合理.
09/23 01:01, 50F
推
09/23 01:03, , 51F
在這種情況下，本來就會命名為 month 吧？ o_O
09/23 01:03, 51F
→
09/23 01:03, , 52F
之前被要求i要改成有意義的單字~像是XXXIndex等~自然名稱
09/23 01:03, 52F
→
09/23 01:03, , 53F
用 i 的情況多是拿來當 dummy 的，若是每個 iteration 有
09/23 01:03, 53F
→
09/23 01:04, , 54F
意義，且不能省略的話，那本來就不該用 i 來命名變數。
09/23 01:04, 54F
→
09/23 01:04, , 55F
對了,其實CC裡也不建議把型別資訊放在prefix裡,不過我自
09/23 01:04, 55F
→
09/23 01:04, , 56F
是又臭又長~如果這又是做為List之類的存取指標~拿出來的物
09/23 01:04, 56F
→
09/23 01:05, , 57F
已是覺得,除非在embedded裡,比較低階的情況才會加type.
09/23 01:05, 57F
→
09/23 01:05, , 58F
件又想直接轉型馬上用~那行程式真是長到不行=.=啥?寫成兩
09/23 01:05, 58F
推
09/23 01:05, , 59F
2和3都沒有follow 1的style，為何3能接受，2就比較不能？
09/23 01:05, 59F
→
09/23 01:06, , 60F
行?這樣是會比較好看沒錯~但心中總覺得指標不要取那麼長就
09/23 01:06, 60F
→
09/23 01:07, , 61F
另外，iterator的意義又不一定總是像month一樣簡單明瞭
09/23 01:07, 61F
→
09/23 01:07, , 62F
好了~有時候程式已經很好看了~再多加什麼只是畫蛇添足...
09/23 01:07, 62F
→
09/23 01:07, , 63F
如果只是小小一段code如把stack裡的東西掃一遍
09/23 01:07, 63F
→
09/23 01:08, , 64F
用 i, j, k 這種約定成俗的 iterator 有何不好？
09/23 01:08, 64F
→
09/23 01:09, , 65F
又，例如在實作演算法時，很多變數都很抽象，
09/23 01:09, 65F
→
09/23 01:10, , 66F
如Warshall的三層loop，每一層的iterator如何取具體的名字?
09/23 01:10, 66F
推
09/23 01:13, , 67F
好不好看,是很主觀的,一個statement裡,塞了一堆運算,跟
09/23 01:13, 67F
→
09/23 01:14, , 68F
有人把for寫成一行,不是很相似嗎? 寫程式應該是盡可能的
09/23 01:14, 68F
→
09/23 01:17, , 69F
讓其他人看得懂才對. 掃stack,是想找什麼東西呢? 那樣東
09/23 01:17, 69F
→
09/23 01:18, , 70F
西的名字就可以拿來取代 i, 至於一些演算法,可以直接拿
09/23 01:18, 70F
→
09/23 01:19, , 71F
原始的paper或書籍來抄命名,如何把名字取得又清楚又不像
09/23 01:19, 71F
→
09/23 01:21, , 72F
又不會太長,就考驗寫程式的人的coding經驗和對該領域的
09/23 01:21, 72F
→
09/23 01:21, , 73F
深度了,多練習,慢慢就會變好.
09/23 01:21, 73F
推
09/23 01:21, , 74F
大多alorithm的原始pesudo就是充滿 i, j, k 啊 :P
09/23 01:21, 74F
推
09/23 01:22, , 75F
噗 該死的 paper 和 itoA 上通通都是 i,j,k XD
09/23 01:22, 75F
→
09/23 01:22, , 76F
很多課本(如 K&R) 或經典的 code 也都有用 i, j, k
09/23 01:22, 76F
→
09/23 01:24, , 77F
另外像stack的例子 具體的變數名是 somthing=stack[i]
09/23 01:24, 77F
推
09/23 01:25, , 78F
軟工也是會進步的,十年前寫coding style的書,和今年出版
09/23 01:25, 78F
→
09/23 01:25, , 79F
而不是在 i 的地方用具體的變數名
09/23 01:25, 79F
→
09/23 01:25, , 80F
的內容就會有不一樣了
09/23 01:25, 80F
→
09/23 01:25, , 81F
因為 i 就只是一個沒有具體意義 iterator
09/23 01:25, 81F
推
09/23 01:26, , 82F
想起我家有本 2x 年的 APPLE BASIC 書, 它也是充斥 i j k :D
09/23 01:26, 82F
→
09/23 01:26, , 83F
那可不可以請a大教我如何簡短又具體的命名Warshall三層loop
09/23 01:26, 83F
推
09/23 01:28, , 84F
可能是 iVertexFrom, iVertexImmd 和 iVertexTo 吧 (誤)
09/23 01:28, 84F
推
09/23 01:29, , 85F
nLoop, nLoop2....nLoopx XD
09/23 01:29, 85F
推
09/23 01:34, , 86F
推前兩樓 XD
09/23 01:34, 86F
推
09/23 14:05, , 87F
java是第三種多...c&c++是第一種多
09/23 14:05, 87F
推
09/23 22:03, , 88F
我應該說 我領域比較偏軟工,所以變數很少用ijk,因為要讓
09/23 22:03, 88F
→
09/23 22:05, , 89F
之後維護的人比較好看code.至於演算法類用ijk倒是沒意見
09/23 22:05, 89F
‣ 更多 TitanSue 的文章
文章代碼(AID): #18rvl9Rj (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 12 之 16 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共16篇)
‣ 更多 TitanSue 的文章
文章代碼(AID): #18rvl9Rj (Soft_Job)