คำถามติดแท็ก coding-style

ในโปรแกรม C ของฉันฉันมักต้องการวิธีในการสร้างการแสดงสตริงของ ADT ของฉัน แม้ว่าฉันไม่จำเป็นต้องพิมพ์สตริงไปที่หน้าจอ แต่อย่างใดมันก็เรียบร้อยที่จะมีวิธีการดังกล่าวสำหรับการดีบั๊ก ฟังก์ชันประเภทนี้มักเกิดขึ้น char * mytype_to_string( const mytype_t *t ); ฉันรู้จริงว่าฉันมี (อย่างน้อย) สามตัวเลือกที่นี่เพื่อจัดการหน่วยความจำสำหรับสตริงที่จะกลับมา ทางเลือก 1: การจัดเก็บสตริงส่งคืนในอาร์เรย์ char แบบคงที่ในฟังก์ชัน ฉันไม่ต้องการคิดมากนักยกเว้นว่าสตริงนั้นจะถูกเขียนทับทุกครั้งที่โทร ซึ่งอาจเป็นปัญหาในบางโอกาส ทางเลือกที่ 2: จัดสรรสตริงบนฮีพด้วย malloc ภายในฟังก์ชัน เรียบร้อยจริงๆตั้งแต่ฉันไม่ต้องคิดขนาดของบัฟเฟอร์หรือการเขียนทับ อย่างไรก็ตามฉันต้องจำให้ฟรี () สตริงเมื่อทำแล้วฉันยังต้องกำหนดให้กับตัวแปรชั่วคราวเช่นที่ฉันสามารถฟรี แล้วการจัดสรรฮีปจะช้ากว่าการจัดสรรสแต็คมากจริงๆดังนั้นจึงเป็นคอขวดถ้าทำซ้ำในลูป ทางเลือก 3: ส่งผ่านตัวชี้ไปยังบัฟเฟอร์และให้ผู้เรียกจัดสรรบัฟเฟอร์นั้น ชอบ: char * mytype_to_string( const mytype_t *mt, char *buf, size_t buflen ); …

11 c  coding-style  strings  malloc 

นี่คือสิ่งที่ฉันทำมากเมื่อเร็ว ๆ นี้ ตัวอย่าง: setCircle(circle, i, { current }) { if (i == current) { circle.src = 'images/25CE.svg' circle.alt = 'Now picking' } else if (i < current) { circle.src = 'images/25C9.svg' circle.alt = 'Pick failed' } else if (i > current) { circle.src = 'images/25CB.svg' circle.alt = 'Pick chance' …

10 coding-style  language-agnostic  conditions 

ฉันมีโครงการที่มีขนาดใหญ่พอที่ฉันไม่สามารถเก็บทุกแง่มุมไว้ในหัวของฉันได้อีก ฉันกำลังจัดการกับคลาสและฟังก์ชั่นจำนวนมากในนั้นและฉันกำลังส่งข้อมูลไปรอบ ๆ เมื่อเวลาผ่านไปฉันสังเกตว่าฉันยังคงได้รับข้อผิดพลาดอยู่เพราะฉันลืมว่ารูปแบบข้อมูลที่แม่นยำมีอะไรบ้างเมื่อฉันส่งมันไปยังฟังก์ชั่นที่แตกต่างกัน ( เช่นหนึ่งฟังก์ชั่นยอมรับและส่งออกอาเรย์ของสตริง ยอมรับสตริงที่ถูกเก็บไว้ในพจนานุกรม ฯลฯ ดังนั้นฉันจึงต้องเปลี่ยนสตริงที่ฉันทำงานด้วยจากการมีสตริงในอาร์เรย์เป็นสตริงในพจนานุกรม ) เพื่อหลีกเลี่ยงการต้องคิดออกว่าเกิดอะไรขึ้นฉันมักจะรักษาแต่ละฟังก์ชั่นและคลาสว่าเป็น "เอนทิตี้แยกตัว" ในแง่ที่ว่ามันไม่สามารถพึ่งพาโค้ดภายนอกที่ให้อินพุตที่ถูกต้องและต้องทำการตรวจสอบอินพุตเอง ในบางกรณีให้กำหนดข้อมูลใหม่หากข้อมูลได้รับในรูปแบบที่ไม่ถูกต้อง) สิ่งนี้ได้ลดเวลาที่ใช้ไปอย่างมากเพื่อให้แน่ใจว่าข้อมูลที่ฉันส่งไป "เหมาะกับ" ในทุกฟังก์ชั่นเพราะตอนนี้คลาสและฟังก์ชั่นของตัวเองเตือนฉันเมื่ออินพุตบางอย่างไม่ดี (และบางครั้งก็แก้ไขได้) ต้องใช้ดีบักเกอร์ผ่านโค้ดทั้งหมดอีกต่อไปเพื่อหาว่ามีอะไรเกิดขึ้นบ้าง อีกทางหนึ่งก็เพิ่มรหัสโดยรวมเช่นกัน คำถามของฉันคือถ้ารูปแบบรหัสนี้เหมาะสมสำหรับการแก้ปัญหานี้หรือไม่ แน่นอนทางออกที่ดีที่สุดคือการ refactor โครงการอย่างสมบูรณ์และตรวจสอบให้แน่ใจว่าข้อมูลมีโครงสร้างที่เหมือนกันสำหรับทุกฟังก์ชั่น - แต่เนื่องจากโครงการนี้เติบโตอย่างต่อเนื่องฉันจะจบลงด้วยการใช้จ่ายมากขึ้นและกังวลเกี่ยวกับรหัสสะอาด . (FYI: ฉันยังเป็นผู้เริ่มต้นดังนั้นโปรดแก้ตัวหากคำถามนี้ไร้เดียงสาโครงการของฉันอยู่ใน Python)

10 python  coding-style  data-structures  refactoring  code-quality 

ฉันได้รับรหัสอันยิ่งใหญ่ที่ฉันได้รวมตัวอย่างสั้น ๆ ของด้านล่าง มีชื่อสำหรับรูปแบบการต่อต้านนี้โดยเฉพาะหรือไม่? มีคำแนะนำอะไรบ้างสำหรับการปรับโครงสร้างนี้ // 0=Need to log in / present username and password // 2=Already logged in // 3=Inactive User found // 4=Valid User found-establish their session // 5=Valid User found with password change needed-establish their session // 6=Invalid User based on app login // 7=Invalid User based …

10 coding-style  code-quality  coding-standards  code-reviews  code-smell 

ฉันทำงานกับสตริงจำนวนมากซึ่งต้องการการจัดการอย่างมาก ตัวอย่างเช่นฉันอาจสร้างสตริงเช่นนี้ ส่วนที่ 1 เรือ ส่วนการ เขียนโปรแกรมA ส่วนที่ 2 การแบ่งพาร์ติชั่นสำหรับการเขียนโปรแกรม ส่วน AA มาตรารายการ SQL สตริงจะใหญ่เกินไปที่จะตรวจสอบด้วยตนเองทุกส่วน ตอนนี้ฉันต้องsplitนี้stringเป็นstringlistโดยส่วนและชิ้นส่วน ฉันนึกถึงตัวเลือกสองทาง: นิพจน์ปกติ: QStringList sl = s.split(QRegularExpression("\n(?=Part [0-9]+|Section [A-Z]+)")); ดูเหมือนว่าจะใช้งานได้ แต่บางครั้งมีข้อยกเว้นเกิดขึ้น (IE: Section SQL Entriesอาจแยกได้) มิฉะนั้นสิ่งที่ฉันสามารถทำได้คือวางเครื่องหมายเมื่อฉันสร้างสตริงเริ่มต้น: art ส่วนที่ 1 เรือ ection ส่วน โปรแกรมA art ส่วนที่2 การแบ่งพาร์ติชันสำหรับการเขียนโปรแกรม ection ส่วนมาตราAA ของมาตรา SQL ซึ่งหมายความว่าการแยกสตริงจะกลายเป็นเรื่องง่าย: QStringList sl = s.split("🚤💻")); …

10 programming-practices  coding-style  coding-standards  strings  regular-expressions 

หลังจากคำตอบที่มีประโยชน์สองสามข้อว่าฉันควรใช้วัตถุโดเมนหรือรหัสที่ไม่ซ้ำกันเป็นพารามิเตอร์วิธีการ / ฟังก์ชั่นที่นี่ตัวบ่งชี้ vs วัตถุโดเมนเป็นพารามิเตอร์วิธีฉันมีคำถามที่คล้ายกันอีกสมาชิก: (การอภิปรายคำถามก่อนหน้านี้ไม่ได้จัดการ ครอบคลุมสิ่งนี้) ข้อดีและข้อเสียของการใช้ ID ที่ไม่ซ้ำกันในฐานะสมาชิก vs object เป็นสมาชิกคืออะไร ฉันกำลังขอให้อ้างอิงกับภาษาที่พิมพ์อย่างมากเช่น Scala / C # / Java ฉันควรจะมี (1) User( id: Int, CurrentlyReadingBooksId: List[Int]) Book( id: Int, LoanedToId: Int ) หรือ (2) เป็นที่ต้องการสำหรับ (1) หลังจากผ่าน: เราควรกำหนดประเภทสำหรับทุกสิ่งหรือไม่ User( id: UserId, CurrentlyReadingBooksId: List[ BookId] ) Book( id: BookId, LoanedToId: …

10 coding-style 

มีบางกรณี (ค่อนข้างหายาก) ที่มีความเสี่ยง: การนำตัวแปรที่ไม่ต้องการนำมาใช้ซ้ำ (ดูตัวอย่างที่ 1) หรือใช้ตัวแปรแทนตัวแปรอื่นปิดความหมาย (ดูตัวอย่างที่ 2) ตัวอย่างที่ 1: var data = this.InitializeData(); if (this.IsConsistent(data, this.state)) { this.ETL.Process(data); // Alters original data in a way it couldn't be used any longer. } // ... foreach (var flow in data.Flows) { // This shouldn't happen: given that ETL possibly …

10 c#  coding-style  language-features  scope 

C ++ มีคุณสมบัติ (ฉันไม่สามารถหาชื่อที่ถูกต้องได้) ซึ่งเรียกการสร้างพารามิเตอร์ที่ตรงกันโดยอัตโนมัติหากประเภทอาร์กิวเมนต์ไม่ใช่ประเภทที่คาดไว้ ตัวอย่างพื้นฐานของสิ่งนี้คือการเรียกใช้ฟังก์ชันที่คาดว่าจะstd::stringมีconst char*อาร์กิวเมนต์ คอมไพเลอร์จะสร้างรหัสโดยอัตโนมัติเพื่อเรียกใช้std::stringConstructor ที่เหมาะสม ฉันสงสัยว่ามันดีสำหรับการอ่านอย่างที่คิดหรือไม่? นี่คือตัวอย่าง: class Texture { public: Texture(const std::string& imageFile); }; class Renderer { public: void Draw(const Texture& texture); }; Renderer renderer; std::string path = "foo.png"; renderer.Draw(path); ไม่เป็นไรใช่ไหม หรือมันไปไกลเกินไป? ถ้าฉันไม่ควรทำฉันจะทำให้ Clang หรือ GCC เตือนได้ไหม?

10 c++  coding-style  readability  type-conversion  construction 

ฉันได้อ่านRefactoringของ Martin Fowler แล้ว โดยทั่วไปถือว่ายอดเยี่ยม แต่คำแนะนำอย่างหนึ่งของ Fowler ดูเหมือนจะก่อให้เกิดปัญหาเล็กน้อย ฟาวเลอร์แนะนำให้คุณแทนที่ตัวแปรชั่วคราวด้วยเคียวรีดังนั้นแทนที่จะเป็น: double getPrice() { final int basePrice = _quantity * _itemPrice; final double discountFactor; if (basePrice > 1000) discountFactor = 0.95; else discountFactor = 0.98; return basePrice * discountFactor; } คุณดึงออกมาเป็นวิธีการช่วยเหลือ: double basePrice() { return _quantity * _itemPrice; } double getPrice() { …

10 coding-style  refactoring  variables 

ฉันมักจะไปที่ตำแหน่งในรหัสของฉันที่ฉันพบว่าตัวเองกำลังตรวจสอบเงื่อนไขที่เฉพาะเจาะจงซ้ำแล้วซ้ำอีก ฉันต้องการให้คุณตัวอย่างเล็ก ๆ : สมมติว่ามีไฟล์ข้อความที่มีบรรทัดที่ขึ้นต้นด้วย "a", บรรทัดที่ขึ้นต้นด้วย "b" และบรรทัดอื่น ๆ และจริง ๆ แล้วฉันต้องการทำงานกับสองบรรทัดแรกเท่านั้น รหัสของฉันจะมีลักษณะเช่นนี้ (ใช้ python แต่อ่านมันเป็นรหัสเทียม): # ... clear_lines() # removes every other line than those starting with "a" or "b" for line in lines: if (line.startsWith("a")): # do stuff elif (line.startsWith("b")): # magic else: # this else is …

10 coding-style  clean-code 

โดยทั่วไปคุณควรหลีกเลี่ยงคำเช่น "handle" หรือ "process" ซึ่งเป็นส่วนหนึ่งของชื่อรูทีนและชื่อคลาสเว้นแต่คุณจะจัดการกับ (เช่น) ไฟล์จัดการหรือ (เช่น) กระบวนการ unix อย่างไรก็ตามคลาสนามธรรมมักไม่รู้จริง ๆ ว่าพวกเขาจะทำอะไรกับบางสิ่งนอกจากพูดประมวลผล ในสถานการณ์ปัจจุบันของฉันฉันมี "EmailProcessor" ที่เข้าสู่กล่องจดหมายของผู้ใช้และประมวลผลข้อความจากมัน มันไม่ชัดเจนเลยสำหรับฉันที่จะตั้งชื่อให้แม่นยำยิ่งขึ้นถึงแม้ว่าฉันจะสังเกตเห็นว่ารูปแบบดังต่อไปนี้เกิดขึ้น: ดีกว่าที่จะรักษาคลาสที่ได้รับในฐานะลูกค้าและตั้งชื่อคลาสพื้นฐานตามส่วนของฟังก์ชันที่ใช้? ให้ความหมายมากกว่านี้ แต่จะละเมิด is-a เช่น EmailAcquirer จะเป็นชื่อที่สมเหตุสมผลเนื่องจากได้มาสำหรับคลาสที่ได้รับมา แต่คลาสที่ได้รับจะไม่ได้รับสำหรับใคร หรือชื่อที่คลุมเครือจริงๆเพราะใครจะรู้ว่าคลาสที่ได้รับมาจะทำอะไร อย่างไรก็ตาม "ตัวประมวลผล" ยังคงกว้างเกินไปเนื่องจากมันเป็นการทำงานที่เกี่ยวข้องมากมายเช่นการเข้าสู่ระบบและการใช้ IMAP มีทางออกจากภาวะที่กลืนไม่เข้าคายไม่ออกนี้ไหม? ปัญหามีความชัดเจนมากขึ้นสำหรับวิธีนามธรรมซึ่งคุณไม่สามารถตอบคำถาม "สิ่งนี้จะทำอย่างไร" เพราะคำตอบนั้นเป็นเพียง "สิ่งที่ลูกค้าต้องการ"

10 object-oriented  coding-style  naming 

ฉันสนับสนุนแนวคิดของการเข้ารหัสกฎสำหรับนักพัฒนาใน บริษัท หรือโครงการเฉพาะเสมอ โดยเฉพาะอย่างยิ่งหาก บริษัท มีขนาดใหญ่กว่า 10 ยิ่ง บริษัท มีความต้องการมากเท่าใด ฉันรู้ว่าผู้คนจำนวนมากจะไม่เห็นด้วย แต่ฉันได้เห็นโครงการที่ไม่มีพวกเขาและรหัสดูเหมือนว่าภัยพิบัติทั้งหมด ปัญหาที่แท้จริงที่มาจากนี้คือวิธีการทำให้คนหัวแข็งที่ไม่ชอบใช้วงเล็บถ้าคำสั่งหรือใช้สตริงการเชื่อมต่อเดียวกันทุกที่ในรหัสหรืออะไรก็ตามที่จะใช้กฎการเข้ารหัสโดยไม่ทำให้พวกเขาต่อต้าน ความคิด?

10 coding  coding-standards  coding-style  company 

เมื่อเร็ว ๆ นี้ฉันได้สลับไปมาระหว่างหลายโครงการและสภาพแวดล้อมการพัฒนา ความคาดหวังของรูปแบบการเข้ารหัสในแต่ละแบบนั้นแตกต่างกัน ตอนนี้คำถามของฉันคือสามส่วนแรกของความอยากรู้: คุณกำหนดและค้นหารูปแบบการเข้ารหัสของคุณได้อย่างไร คุณจะเพิ่มพูนและปรับปรุงมันอย่างไร? คุณรักษามันอย่างไร? (จากบันทึกย่อทางจิตการเก็บรักษาเอกสารการใช้เครื่องมือเช่น StyleCop เป็นต้น)

10 coding-style  maintenance 

โดยทั่วไปเมื่อประกาศคลาส C ++ เป็นแนวปฏิบัติที่ดีที่สุดที่จะใส่เฉพาะการประกาศในไฟล์ส่วนหัวและวางการประยุกต์ใช้ในไฟล์ต้นฉบับ อย่างไรก็ตามดูเหมือนว่ารูปแบบการออกแบบนี้จะไม่ทำงานกับคลาสเทมเพลต เมื่อดูทางออนไลน์มีความคิดเห็น 2 ข้อเกี่ยวกับวิธีที่ดีที่สุดในการจัดการคลาสเทมเพลต: 1. การประกาศทั้งหมดและการใช้งานในส่วนหัว สิ่งนี้ค่อนข้างตรงไปตรงมา แต่นำไปสู่สิ่งที่ฉันคิดว่าเป็นเรื่องยากที่จะรักษาและแก้ไขไฟล์โค้ดเมื่อเทมเพลตมีขนาดใหญ่ 2. เขียนการใช้งานในเทมเพลตรวมไฟล์ (.tpp) ที่รวมอยู่ท้าย ดูเหมือนว่าจะเป็นทางออกที่ดีกว่าสำหรับฉัน แต่ดูเหมือนจะไม่ได้ใช้อย่างกว้างขวาง มีเหตุผลที่วิธีนี้ด้อยกว่าหรือไม่? ฉันรู้ว่าหลายครั้งที่รูปแบบของรหัสถูกกำหนดโดยการตั้งค่าส่วนตัวหรือรูปแบบดั้งเดิม ฉันกำลังเริ่มโครงการใหม่ (การย้ายโครงการ C เก่าไปยัง C ++) และฉันค่อนข้างใหม่ในการออกแบบ OO และต้องการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดตั้งแต่เริ่มต้น

10 object-oriented  c++  coding-style  templates 

มีข้อโต้แย้งวัตถุประสงค์สำหรับหรือต่อต้านการใช้วัตถุกับ ID ที่ไม่ซ้ำกันเป็นพารามิเตอร์วิธีการ / ฟังก์ชั่น? (และสมาชิกของวัตถุอื่น ๆ ?) เป็นพิเศษในบริบทของภาษาที่พิมพ์แบบคงที่ (C # / Java / Scala) ข้อดีของวัตถุเอง: โทร typesafe เพิ่มเติม ด้วย IDs มีความเสี่ยงในการเรียงลำดับอาร์กิวเมนต์อย่างไม่ถูกต้อง สิ่งนี้สามารถบรรเทาได้ด้วยการรักษาคลาส 'มินิ' สำหรับแต่ละคลาสที่เก็บ ID ของคลาสนั้นเท่านั้น รับเพียงครั้งเดียวจากการคงอยู่ไม่จำเป็นต้องกลับมาอีก ด้วย ID หากการเปลี่ยนแปลงประเภท id บอกว่า int -> long จะต้องมีการเปลี่ยนแปลงทั่วกระดานโดยอาจเกิดข้อผิดพลาด .. (courtey: https://softwareengineering.stackexchange.com/a/284734/145808 ) ข้อดีของการใช้ ID: เวลาส่วนใหญ่ไม่จำเป็นต้องใช้วัตถุจริงเพียง แต่เอกลักษณ์จะทำดังนั้นการมี ID ช่วยประหยัดเวลาจากการทำให้มันคงอยู่ การผสมผสานของเทคนิคเหล่านี้เท่าที่ฉันเห็นมีเพียงข้อเสียของทั้งสองและข้อดีของทั้งสองอย่าง ระบุว่านี่เป็นปัญหาที่กำหนดไว้อย่างชัดเจนฉันหวังว่าจะมีคำตอบที่ตรงตามวัตถุประสงค์และไม่ใช่ - …

10 coding-style  methods  parameters