มีแบบแผนการตั้งชื่อสำหรับที่เก็บคอมไพล์หรือไม่?

328

ตัวอย่างเช่นฉันมีบริการสงบที่เรียกว่าบริการการซื้อ ฉันควรตั้งชื่อที่เก็บของฉัน:

purchaserestservice
purchase-rest-service
purchase_rest_service
หรืออย่างอื่น?

การประชุมคืออะไร? แล้วใน Github ล่ะ? ที่เก็บข้อมูลสาธารณะควรเป็นไปตามมาตรฐานหรือไม่

git github naming-conventions

— Adrian M
แหล่งที่มา

4

โพสต์บล็อกนี้อาจจะมีการใช้บางgravitydept.com/blog/...

— PHeiberg

379

purchase-rest-serviceฉันต้องการไปสำหรับ เหตุผล:

"pur chase rests ervice" คืออะไร คำที่ต่อกันยาว ๆ ยากที่จะเข้าใจ ฉันรู้ว่าฉันเป็นคนเยอรมัน "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung."
"_" พิมพ์ยากกว่า "-"

— Aaron Digulla
แหล่งที่มา

151

ฉันไม่เข้าใจ (จริง ๆ ) แต่คุณไม่พลาด S ใน ... auschreibung ... ?

— Vili

6

@adimauro: มันเป็นแอปพลิเคชั่นสำหรับตำแหน่งเปิดในฐานะผู้ช่วยในการกรอกแบบฟอร์มสำหรับสิทธิบัตรกัปตันของเรือกลไฟดานูบ

— Aaron Digulla

6

มีเหตุผลใดที่คุณไม่ชอบ camelCase ไหม? นั่นเป็นหลักการตั้งชื่อทั่วไปของไอเท็มทั่วไปเนื่องจากไม่มีอักขระพิเศษ

— 10gistic

31

@ 10gistic ชื่อ repo มักจะเห็นใน URL (เช่นบน GitHub) ที่อาจไม่ตรงตามตัวพิมพ์ใหญ่ - เล็กหรือแปลงเป็นตัวพิมพ์เล็กและด้วยเหตุนี้ camelCase จึงเป็นแนวคิดที่ไม่ดี ฉันไม่คิดว่า github ทำเช่นนี้ แต่ก็ยังดีกว่าที่จะได้รับการบันทึก

— jdg

19

ผู้ชายใน GitHub ใช้ยัติภังค์ habrastorage.org/getpro/habr/post_images/d34/331/a8d/…

— airato

72

ปัญหาเกี่ยวกับกรณีอูฐคือมักจะมีการตีความคำที่แตกต่างกัน - เช่น checkinService vs checkInService ถ้าคุณมี repos ที่มีชื่อคล้ายกันมากมายให้ตรวจสอบอย่างต่อเนื่องว่าคนที่สร้าง repo ที่คุณสนใจนั้นใช้การแบ่งย่อยของส่วนบนและส่วนล่างที่แน่นอนหรือไม่ หลีกเลี่ยงตัวพิมพ์ใหญ่

จุดของเขาเกี่ยวกับขีดคั่นยังเป็นคำแนะนำที่ดี

ใช้ตัวพิมพ์เล็ก
ใช้เครื่องหมายขีดกลาง
เฉพาะเจาะจง. คุณอาจพบว่าคุณต้องแยกความแตกต่างระหว่างความคิดที่คล้ายกันในภายหลัง - ใช้บริการซื้อส่วนที่เหลือแทนบริการหรือบริการส่วนที่เหลือ
คงเส้นคงวา. พิจารณาการใช้งานจากผู้ขาย GIT ต่างๆ - คุณต้องการให้ที่เก็บของคุณเรียงลำดับ / จัดกลุ่มอย่างไร

— Matthew Sandoz
แหล่งที่มา

3

คำตอบของคุณสัมผัสกับประเด็นสำคัญสองประการที่คำตอบยอดนิยมไม่ได้

— Will Beason

4

ลืมได้อย่างไรว่าบริการเช็คอินหรือเช็คอินดีกว่าลืมบริการเช็คอินหรือบริการเช็คอิน

— MarredCheese

เคสอูฐนั้นยากสำหรับผู้ที่ไม่ได้พูดภาษาไทยด้วย

— Ben Aveling

48

lowercase-with-hyphens เป็นสไตล์ที่ฉันเห็นบ่อยที่สุดบน GitHub *

lowercase_with_underscores น่าจะเป็นสไตล์ยอดนิยมอันดับสองที่ฉันเห็น

อดีตคือความชอบของฉันเพราะมันช่วยกดแป้นพิมพ์

^{* ประวัติย่อ; ฉันไม่ได้รวบรวมข้อมูลใด ๆ}

— เดนนิส
แหล่งที่มา

8

ยัติภังค์ยังมีข้อได้เปรียบ SEO สิ่งนี้อาจไม่ใช่ข้อพิจารณาที่สำคัญ แต่เนื่องจากเรากำลังพูดถึง URL จึงมีความเกี่ยวข้อง

— Michael Scheper

12

ยัติภังค์ยังมีข้อได้เปรียบอีกประการหนึ่งคือพวกมันสามารถมองเห็นได้ง่ายในไฮเปอร์ลิงก์ที่ขีดเส้นใต้

— Jeroen

1

ยากที่จะเก็บข้อมูลที่คุณได้กล่าวถึง แต่ผมไปgithub.com/trending/developersและเห็นเพียงรูปแบบเดิมที่ได้รับการกล่าวถึง:lowercase-with-hyphens

— SATA

21

โดยไม่นิยมตัวเลือกการตั้งชื่อใด ๆ โปรดจำไว้ว่า repo git สามารถถูกโคลนลงในไดเรกทอรีรากใด ๆ ที่คุณเลือก:

git clone https://github.com/user/repo.git myDir

นี่repo.gitจะถูกโคลนลงในmyDirไดเรกทอรี

ดังนั้นแม้ว่าแผนการตั้งชื่อของคุณสำหรับ repo สาธารณะจะไม่ถูกต้องเล็กน้อย แต่ก็ยังคงเป็นไปได้ที่จะแก้ไขในฝั่งไคลเอ็นต์

นั่นคือเหตุผลว่าทำไมในสภาพแวดล้อมแบบกระจายที่ลูกค้าสามารถทำอะไรก็ได้ตามที่ต้องการ / ไม่มีแบบแผนการตั้งชื่อสำหรับ repo ของ Git
(ยกเว้นเพื่อสำรอง " xxx.git" สำหรับรูปแบบเปลือยของ repo ' xxx')
อาจมีการตั้งชื่อแบบแผนสำหรับบริการ REST (คล้ายกับ " มีแนวทางแบบแผนการตั้งชื่อสำหรับ REST API หรือไม่ ") แต่นั่นเป็นปัญหาแยกต่างหาก

— VonC
แหล่งที่มา

4

จุดดี. อย่างไรก็ตามการแก้ไขชื่อ repo ในฝั่งไคลเอ็นต์ค่อนข้างพิสูจน์ได้ว่าการมีการตั้งชื่อจะเป็นประโยชน์ คุณไม่คิดเหรอ ทำไมต้องแก้ไขถ้ามันเป็นไปตามอนุสัญญาในตอนแรก? บางที Maven มีอิทธิพลต่อฉันมาก

— เอเดรียน M

1

@AdrianM ประเด็นของฉันคือ: ใช่การตั้งชื่อการประชุมมีประโยชน์ แต่ไม่มีอะไรเกี่ยวข้องกับ Git หรือ GitHub และทุกสิ่งที่คุณต้องการจะทำกับ repo นั้น ดังนั้นคำตอบสำหรับคำถามของคุณคือ "ไม่ไม่มีแบบแผนการตั้งชื่อสำหรับที่เก็บคอมไพล์"

— VonC

8

อาจเป็นเพียงพื้นหลัง Java และ C ของฉันแสดง แต่ฉันชอบ CamelCase (CapCase) มากกว่าการใช้เครื่องหมายวรรคตอนในชื่อ เวิร์กกรุ๊ปของฉันใช้ชื่อดังกล่าวอาจจะตรงกับชื่อของแอพหรือบริการที่เก็บมี

— SteveW
แหล่งที่มา

6

โพสต์นี้เบาบางและไม่ใช่ความชอบส่วนตัวของฉัน แต่เขาก็ยังกล่าวถึงประโยชน์ว่าชื่อโครงการใน Java เป็นกรณีอูฐและมีความสะดวกสบายในความสอดคล้องกัน เราแน่ใจว่า downvotes ที่นี่ไม่ใช่แค่การตั้งชื่ออคติที่กำลังคืบคลานเข้ามาใช่ไหม

— eremzeit

1

ตกลง คำตอบอื่น ๆ พูดถึงข้อเสียของ camelCase แต่ในโลก Java มันจะสมเหตุสมผลในการตัดสินใจ camelCase จะดีกว่าอย่างไรก็ตามโดยเฉพาะอย่างยิ่งสำหรับโครงการที่ไม่รู้โลกของ Windows

— Michael Scheper

11

ประกาศบริการสาธารณะ Pedantic: PascalCase ไม่ใช่ camelCase

— MarredCheese

0

หากคุณวางแผนที่จะสร้างแพคเกจ PHP คุณน่าจะต้องการที่จะนำในPackagistที่จะทำให้มันสามารถใช้ได้สำหรับการอื่น ๆ ที่มีนักแต่งเพลง นักแต่งเพลงที่มีเป็นตั้งชื่อ-ประชุมvendorname/package-name-is-lowercase-with-hyphensกับการใช้งาน

หากคุณวางแผนที่จะสร้างแพ็คเกจ JS คุณอาจต้องการใช้ npm หนึ่งในแผนการตั้งชื่อของพวกเขาคือไม่อนุญาตให้ใช้ตัวอักษรตัวพิมพ์ใหญ่ในชื่อกลางของแพ็คเกจของคุณ

ดังนั้นฉันขอแนะนำสำหรับแพ็คเกจ PHP และ JS ให้ใช้lowercase-with-hyphensและตั้งชื่อแพ็คเกจของคุณเป็นผู้แต่งหรือ npm เหมือนกับแพ็คเกจของคุณใน GitHub

— อาดัม
แหล่งที่มา