เป็นความคิดที่ดีหรือไม่ที่จะแสดงรายการอาร์กิวเมนต์ของฟังก์ชัน / เมธอดทุกรายการในบรรทัดใหม่และเพราะเหตุใด

22

ฉันทำงานกับใครบางคนทุกครั้งที่พวกเขาเรียกฟังก์ชั่นที่พวกเขาวางข้อโต้แย้งในบรรทัดใหม่เช่น

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

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

coding-style

— แดเนียลบอล
แหล่งที่มา

25

+1 ฉันไม่รู้จักตอบคำถามของคุณ แต่ฉันเกลียดสิ่งนี้เช่นกัน หากคุณมีข้อโต้แย้งมากมายในฟังก์ชั่นอย่างไรก็ตามฟังก์ชั่นของคุณอาจทำมากเกินไป

— maple_shaft

28

ยิ่งกว่านั้นทำไมเรายังต้องเห็นความชอบของแต่ละคนเกี่ยวกับเรื่องนี้? เหตุใด IDEs ของเราไม่สามารถแสดงในสไตล์ที่เราต้องการได้โดยอัตโนมัติ

— Alex Feinman

5

ไมค์ฉันชอบมีรหัสใช้เวลาน้อยที่สุดหน้าจออสังหาริมทรัพย์ แต่มันเป็นการประนีประนอม ฉันใส่ {ลงในบรรทัดแยกต่างหากเพราะมันทำให้การจับคู่กับการปิด} ง่ายขึ้นและเข้าใจขอบเขตของบล็อกได้อย่างถูกต้อง มันคุ้มค่ากับการเสียการสูญเสียแถวของหน้าจออสังหาริมทรัพย์

— Brian Schroth

2

@Alex: คุณพูดถูก ฉันคิดว่าสิ่งที่ถูกต้องที่ควรทำคือมีภาษาที่ต้นไม้ในการแยกวิเคราะห์โค้ดถูกเก็บไว้ในดิสก์และแสดงตามความต้องการของผู้ใช้

— Neil G

1

@maple_shaft ฉันดูถูกงบแบบนั้น ไม่ใช่เพราะไม่มีความจริงใด ๆ แต่เป็นเพราะคนจำนวนมากเกินไปทำตามคำแนะนำดังกล่าวโดยไม่ต้องออกจากห้องเพื่อความแตกต่างกันนิดหน่อย

— Stijn

38

มันเป็นเพียงแนวทางการเข้ารหัสที่คุณอาจจะชอบหรือไม่ชอบ สิ่งสำคัญคือคุณและเพื่อนร่วมงานของคุณตกลงที่จะใช้หรือไม่

วิธีที่ดีที่สุดในการเพิ่มความสามารถในการอ่านคือการ จำกัด จำนวนอาร์กิวเมนต์

— Martin Wickman
แหล่งที่มา

24

มีคนจำนวนมากลดข้อโต้แย้งด้วยการเททิ้งในอาเรย์ ฉันอยากเห็นความยุ่งเหยิงน่าเกลียดกว่ารหัสที่ดูดีกว่าและมีความซับซ้อนซ่อนอยู่

— Satanicpuppy

18

อาร์เรย์ไม่ใช่วิธีที่จะไป อาจมีโครงสร้างซ่อนอยู่ใน args หรืออาจจะเป็นฟังก์ชั่นที่ทำมากเกินไปและควรจะแยกกัน

— Michael K

4

ฉันพบว่าการใช้หลายบรรทัดช่วยให้โค้ด IF ที่อ่านได้เป็นนิพจน์ที่ยาวหรือน้อยเกินไป มิฉะนั้นมันก็น่ารำคาญ

— PedroC88

3

วางพวกเขาในวัตถุการถ่ายโอนข้อมูลเพียงแค่ย้ายปัญหา หากจำเป็นต้องมีอาร์กิวเมนต์ทั้งหมดทั้งหมดจะต้องเป็นอาร์กิวเมนต์ที่จำเป็นของ Constructor ของ DTO ซึ่งหมายความว่าคุณยังคงมีอาร์กิวเมนต์มากมาย

— Scott Whitlock

21

มันเป็นเรื่องของการตั้งค่า สำหรับการเรียกใช้ฟังก์ชันที่ซับซ้อนที่คุณต้องการจัดทำเอกสารพารามิเตอร์แต่ละตัวหรือตัวแปรที่มีความยาวและมีจำนวนมากสิ่งเหล่านี้อาจดี

ตัวอย่างเช่น:

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

ด้วยภาษาที่อนุญาตให้ใช้พารามิเตอร์ที่ตั้งชื่อสิ่งนี้จะเป็นเรื่องธรรมดามากขึ้นถ้าคุณใช้ชื่อพารามิเตอร์ (ตัวอย่างใน PL / SQL):

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray);

แต่ฉันเห็นด้วยกับคุณว่าถ้าการเรียกฟังก์ชันนั้นง่ายและไม่มากเกินไปพารามิเตอร์สิ่งนี้อาจทำให้เกิดความรำคาญเช่น:

setColour (
    r,
    g,
    b
 );

ฉันพบว่าอ่านง่ายกว่ามาก

 setColour(r,g,b);

สำหรับ @ammoQ:

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

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

11

ตัวอย่างแรกคือคำตอบที่ผิดสำหรับปัญหาจริง ทำไมไม่ใช้ตัวแปร anmes ที่ชัดเจนตั้งแต่แรก?

— deadalnix

@deadalnix: จุดดีทำความสะอาดขึ้นเล็กน้อย

— FrustratedWithFormsDesigner

1

จริง อย่างไรก็ตามมันไม่ได้เป็นปัญหากับชื่อตัวแปรเสมอไป เป็นเรื่องเกี่ยวกับชื่อตัวแปรแบบยาวอาร์กิวเมนต์ที่มีค่าเริ่มต้นเป็นต้น

— inspectorG4dget

4

ฉันจะโต้แย้งทางออกที่ดีกว่าปัญหาคือ refactor do_complex_op () ดังนั้นจึงใช้โครงสร้างเป็นพารามิเตอร์ จากนั้นคุณสามารถทำได้do_complex_op(new paramStruct { StartingState = 0, XCoord = xcoord })จากนั้นจะกลายเป็นเอกสารด้วยตนเองและอ่านง่ายขึ้นมาก

— KallDrexx

1

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

— FrustratedWithFormsDesigner

10

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

พิสูจน์ได้ว่ามันเป็นเรื่องธรรมดาที่ค่อนข้างง่ายแสดงแหล่งที่มาของตัวอย่างใน MSDN หรือเว็บไซต์ที่คล้ายกันแสดงฐานโอเพนซอร์สขนาดใหญ่ ฯลฯ แสดงผลลัพธ์ของรหัส beautifiers ในท้ายที่สุดแสดงให้เห็นว่าคนอื่นในทีมของคุณทำอะไร อย่ายอมรับสไตล์ที่ไม่ดีเพียงเพราะบางคนดื้อเกินไป

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

หืม ... ด้วยวิธีการนั้นเราจะแนะนำวิธีปฏิบัติที่ดีที่สุดแบบใหม่ได้อย่างไร (หรือถูกต้องอย่างน่าทึ่ง: วิธีปฏิบัติที่ดีกว่า )

— Treb

2

Treb: แน่นอนว่าเพียงแค่แสดงให้เห็นว่าการปฏิบัติที่ดีกว่าในความเป็นจริงดีกว่าไม่เพียง แต่แตกต่างกัน

— 281377

4

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

— Toby

2

Meh "ยากต่อการอ่าน" สามารถวัดได้อย่างเป็นกลาง มันแค่มีแนวโน้มที่จะไม่เป็น การโต้เถียงเกี่ยวกับมันสนุกกว่า

— JasonTrue

1

สามารถวัดได้อย่างเป็นกลาง แต่ไม่แยกอิสระจากบุคคลที่ทำการอ่าน

— jk

9

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

แต่ข้อกังวลหลักของฉันไม่ใช่ว่ารหัสนั้น "น่าเกลียด" หรือ "สวย" ข้อกังวลหลักของฉันคือการเข้าใจและเปลี่ยนแปลงโดยง่ายโดยไม่ทำผิด

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

ฉันยังต้องการลดโอกาสในการทำผิดพลาดให้น้อยที่สุดถ้าฉันเพิ่มหรือลบอาร์กิวเมนต์ไปยังฟังก์ชันซึ่งมีแนวโน้มที่จะเกิดขึ้นในตอนท้ายของรายการอาร์กิวเมนต์มากกว่าตอนเริ่มต้น ด้วยเหตุนี้ฉันจึงต้องการใส่เครื่องหมายจุลภาค (,) ที่จุดเริ่มต้นของบรรทัดมากกว่าตอนท้าย จากนั้นถ้าเช่นฉันต้องการลบหรือเพิ่มข้อโต้แย้งในตอนท้ายของรายการมันเป็นการแก้ไขแบบบรรทัดเดียว ฉันไม่ต้องไปเล่นกับคอมมาที่จำเป็นต้องไปที่จุดสิ้นสุดของทุกบรรทัด แต่สุดท้ายซึ่งสุดท้ายจะต้องจบด้วยวงเล็บ

ดังนั้น (เด็กผู้ชายฉันจะโดนเผาอย่างนี้) ฉันเขียนแบบนี้:

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

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

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

— Mike Dunlavey
แหล่งที่มา

1

ฉันคิดว่านี่เป็นคำตอบที่ดีเพราะคุณอธิบายเหตุผลของคุณได้ดี เก่งมากไมค์

— Jordan

8

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

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

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

5

มันทำให้ง่ายต่อการ:

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

— เกรแฮมบอร์แลนด์
แหล่งที่มา

4

ฉันจะบอกว่าการเรียกใช้ฟังก์ชั่นควรอยู่ในบรรทัดเดียวยกเว้นว่าพวกเขามีความสำคัญเกินกว่าความกว้างของรหัสมาตรฐานของคุณ (มักจะเป็น 80 ตัวอักษรมักเป็นสาเหตุของข้อโต้แย้ง :-)

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

— ลุคเกรแฮม
แหล่งที่มา

สิ่งที่ตัวละคร 80 ต้องดำเนินการไปไม่มีเหตุผลใด ๆ ที่ใช้ได้จริงในเรื่องเทคนิคอีกต่อไป ตอนนี้เราอยู่ในยุคของจอภาพ 19xx X 16xx และปรับขนาดตัวอักษรและขนาดตัวอักษร

— anon

4

@anon: เหตุผลที่ถูกต้องหรือไม่ ทำไมคุณคิดว่าข้อความพิมพ์ในคอลัมน์และหนังสือแคบกว่าที่ควรจะเป็น เพราะดวงตาของมนุษย์สูญเสียการติดตามเมื่ออ่านข้ามเส้นที่ยาวมาก ๆ

— Zan Lynx

4

@ อานนท์: ฉันชอบที่จะใช้หน้าจอไวด์สกรีนเพื่อเปิดไฟล์สองหรือสามไฟล์ในแนวนอนแยกซึ่งกลับไปเป็นอักขระ 80-100 ตัวในหนึ่งบรรทัด

— Zan Lynx

4

@ anon: ไม่มีทางเทคนิคจริง: นรกใช่ Zan Lynx นั้นถูกต้องอย่างสมบูรณ์รวมทั้งมีเหตุผลเพิ่มเติม: การผสาน diff โดยใช้โปรแกรมอรรถประโยชน์บรรทัดคำสั่ง ... โอ้และโชคดีที่มุ่งเน้นไปที่ตัวอักษร 8p ในขณะที่คุณแก่ขึ้น: o)

— MaR

3

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

— Karl Bielefeldt
แหล่งที่มา

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

— BillThor

2

มันเป็นไปตามมาตรฐานการเข้ารหัสของ บริษัท หรือไม่

ถ้าไม่เช่นนั้นเริ่มต้นการสนทนาเกี่ยวกับมาตรฐานและสิ่งที่ผู้คนต้องการที่จะเห็นการเปลี่ยนแปลง ตรวจสอบให้แน่ใจว่าคุณนำสิ่งนี้มาเป็นหนึ่งในสิ่งที่คุณต้องการเปลี่ยนแปลง

มีการอภิปรายอย่างสมบูรณ์เกี่ยวกับสาเหตุที่คุณไม่คิดว่าสิ่งนี้มีประโยชน์และหวังว่าคุณจะชนะในวันนี้ คุณไม่เคยรู้ว่าเพื่อนร่วมงานของคุณอาจโน้มน้าวใจคุณว่าวิธีการของเขาดีที่สุดหลังจากทั้งหมด;)

เมื่อคุณได้รับมาตรฐานที่อัปเดตแล้วจะมีการบันทึกสิ่งที่ทุกคนควรเขียนไว้ดังนั้นหากเพื่อนร่วมงานของคุณยังคงทำสิ่งนี้อยู่

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

2

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

อ่านง่ายกว่า:

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

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

ส่วนที่สำคัญคือรหัสของคุณสามารถพิมพ์หรือแสดงผลแบบมาตรฐาน 80 หน้าจอสีและยังอ่านง่าย

— เอ็ดเวิร์ดแปลก
แหล่งที่มา

2

คุณจะไม่ค่อยได้รับคำตอบที่ซื่อสัตย์จากโปรแกรมเมอร์สำหรับสิ่งนี้ ทุกคนจะตอบด้วยสิ่งที่พวกเขาทำหรือไม่ชอบ ความจริงก็คือเท่าที่เราทุกคนต่อสู้กับมันในเวลาที่ "การปฏิบัติที่ไม่ดี" เพียงอย่างเดียวที่นี่คือความยืดหยุ่นของคุณเอง

คุณต้องซื่อสัตย์ต่อตัวเองอย่างไร้ความปราณีเพื่อให้สามารถแยกแยะความแตกต่างระหว่างสิ่งที่ไม่ดีจริง ๆ กับสิ่งที่รบกวนคุณ ความจริงก็คือในภาษา C / C ++ และภาษาที่คล้ายกันคุณจะไม่ค่อยพบวิธีการเยื้องที่ส่งผลกระทบอย่างเป็นรูปธรรมต่อความเข้าใจของโค้ด การอภิปรายส่วนใหญ่เกี่ยวกับสิ่งต่าง ๆ เหล่านี้มีทั้งสองด้านซ้อนกันกับผู้คนที่สร้างข้อโต้แย้งที่ไร้สาระและไร้เล่ห์เหลี่ยมเพื่อพยายามพิสูจน์ความชอบส่วนตัวของตนเอง

สิ่งที่ฉันอ่าน ... เป็นสิ่งที่คุณขอในคำถามนี้: อาร์กิวเมนต์ที่ไร้สาระและมีเลศนัยเพื่อพิสูจน์ความชอบส่วนตัวของคุณ

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

0

ความซื่อสัตย์มันขึ้นอยู่กับบุคคล .. ฉันอยากจะพูดถึงฟังก์ชั่นที่ซับซ้อนตามตัวอย่างแรกจาก FrustratedWithForms ใช่แล้ว; ไม่เช่นนั้นใหญ่ แล้วอีกครั้งนี่คือเหตุผลที่ฉันต้องการใช้ฟังก์ชัน IDE ของโค้ดโดยพลการ

— Dark Star1
แหล่งที่มา

0

"ฉันสนใจที่จะรู้ว่านี่เป็นการปฏิบัติที่ไม่ดีจริง ๆ หรือไม่ ... "

ใช่มันเป็นการปฏิบัติที่ไม่ดียกเว้นเมื่อรายการตัวแปรมีความยาวผิดปกติ แต่ในกรณีนี้ปัญหาน่าจะเกิดจากการออกแบบฟังก์ชั่น ทำไมไม่ผ่านวัตถุที่สรุปหลายพารามิเตอร์?

"... และถ้าเป็นเช่นนั้นฉันจะเกลี้ยกล่อมพวกเขาไม่ให้ทำอย่างไร"

ผูกพวกเขาลงและกระตุ้นพวกเขาต่อไปจนกว่าพวกเขาจะตกลงหยุดอึนั้น

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

"ทำไมไม่ผ่านวัตถุที่ห่อหุ้มพารามิเตอร์หลายตัว?" ตกลงตอนนี้คุณได้ย้ายปัญหาไปยังวัตถุใหม่นั้น มันยังคงต้องการพารามิเตอร์จำนวนเท่ากัน (ผ่าน Constructor เป็นต้น) ดังนั้นคุณยังคงมีปัญหาเดียวกัน

— Stijn

-2

เหตุใดคุณจึงสูญเสียวงจรในข้อกังวลเล็ก ๆ น้อย ๆ นี้? เพียงเปิดไฟ IDE ที่ไว้ใจได้ของคุณเปิดไฟล์และฟอร์แมตใหม่ Voila! มันจะอยู่ในรูปแบบที่คุณต้องการ

ทีนี้เรามาพูดถึงประเด็นที่สำคัญจริงๆ - vi หรือ emacs, LOL

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

และเมื่อคุณมาตรวจสอบสิ่งนั้นลงในการควบคุมแหล่งที่มา?

— pdr

-2

ฉันจะบอกว่าถ้าข้อโต้แย้งพอดีกับหนึ่งบรรทัดทำเช่นนั้น ถ้าไม่เช่นนั้นจะมีหนึ่งอาร์กิวเมนต์ต่อบรรทัดทำให้อ่านง่าย

foo(arg1, arg2, arg3, arg4, arg5)

เมื่อเทียบกับ

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)

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

3

นี้ไม่ได้ดูเหมือนจะนำเสนออะไรที่สำคัญกว่าจุดทำและอธิบายในก่อน 14 คำตอบ

— ริ้น