Re: [問題] Res values 取名的方式

[NewSpec (新規格)]

※ 引述《lovelycateye (我還想要更多力量)》之銘言：
: ※ 引述《NewSpec (新規格)》之銘言：

: :  所以其實id的命名並不需要使用前綴
: :  在id的命名上, 如果用了前綴反而會大大增加id的數量, 造成管理的麻煩

: 講到這個其實我對layout中每個元件的id其實命名上我也是會加上前綴
: 原因其實很簡單，因為我常常忘記我剛剛取的id叫啥。
: 漸漸的，我開始在只屬於某個activity的layout開始也會加上前綴。
: 這樣省去我回憶我剛剛取啥名字的麻煩。
: 不過需要加上id的元件數量應該是固定的，我不懂為何會增加id的數量？
: 因為我只會對需要操作的元件加上id。

 舉個常見的例子, 假設我現在在開發一個"不是太簡單"的儲存資料類型app

 (例如 todo list, 記帳程式 等)

 我們會有多個呈現多筆資料的頁面, 呈現單筆資料詳細內容的頁面,

 以及輸入資料的頁面

 假設我現在有２個用以呈現"多筆資料"的頁面, 那大概一定會使用ListView

 如果我在這兩個layout file中分別為這兩個ListView的id名加上前綴

 那可能就是 "@+id/a_main_list" 與 "@+id/b_main_list"

 但事實上並不需要

 因為這兩個ListView不會同時被inflate出來並被使用

 因此在這兩個layout file中都只須把它們取名為 @+id/main_list 即可


 看起來這似乎無關痛癢

 但我之前曾經接過一個律師事務所的案子

 他想把他們的業務做成一個app, 他們大概有七大業務

 每個業務都有案件總覽 案件細節 建立案件等功能, 而且基本上都大同小異

 如果我為每個業務的每個頁面ui元件都建立個別的id名

 id resource很容易就超過200個了... 但是事實上根本不需要

 ooo_sn_edit, xxx_sn_edit, ..., qqq_sn_edit 完全可以只用 sn_edit 一個代表

 大概是這個意思@@"

: 所以增加字數可以理解，但不懂為何會增加數量還請大大開示。
: 另外其實我在不同類型的layout、drawable
: 我都開始有加前綴（類別）或甚至後綴（狀態）的習慣。
: 一切只是為了方便能夠一目了然，方便管理。
: 例如：
: drawable會有btn_back.xml
: drawable-mdpi和xhdpi會有btn_back_normal.9.png、btn_back_pressed.9.png
: 以上僅為我個人的命名習慣，請用力鞭我

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 36.224.228.181
推 givemepass:不知道有沒有誤解你的意思 可是我覺得這樣做會有代價的
→ givemepass:你這樣的前提是 兩個layout必須是可以同時變化的
→ givemepass:假設你A layout跟 B layout不一定資料是相同
→ givemepass:哪天你改了A layout 卻連B layout的資料一起改了
→ givemepass:我目前也是採用lovelycateye 大所使用的方法
推 lovelycateye:我覺得他講的跟樓上你想的不太一樣XD
→ NewSpec:是的= =
→ NewSpec:我之前也是以使用前綴的思維來做, 後來有到stackoverflow
→ NewSpec:發問, 才被人點醒
推 MetalChao:方便給stackoverflow的連結嗎? 想看看關鍵在哪裡
推 givemepass:哈哈 那我想錯了
→ MetalChao:如果真的有很大的好處, 我也可以改變習慣
推 lovelycateye:好處是沒有多大，不過我倒覺得寫一樣當遇到要一起用
→ lovelycateye:反而要開始改東改西，而且id多會造成問題嗎？
推 MetalChao:因為不清楚會有什麼的好處, 所以想請原PO給個連結來看看
→ NewSpec: http://goo.gl/Jagkh
→ NewSpec:好處就是不需要管理太多的id = =
推 lovelycateye:但缺點也如同回答的一樣，這是我那種寫法的優點
→ lovelycateye:我在寫的時候就可以知道這東西是不是這個地方該出現