การตั้งชื่อวิธีบูล: vs. vs. Can vs. ?

ชื่อที่ดีกว่าสำหรับวิธีการที่ส่งกลับบูลีนคืออะไร?

IsSupportContentType

หรือ

CanSupportContentType

naming naming-standards

— สื่อกลาง
แหล่งที่มา

เนื่องจากเจตนาสำหรับชื่อที่จะสื่อถึงสถานะหรือพฤติกรรมอย่างชัดเจนและคุณจะไม่พูดว่า "คลาสนี้รองรับเนื้อหาประเภท X" ชื่อที่ดีกว่าคือ CanSupportContentType คุณอาจพูดว่า "คลาสนี้สามารถรองรับประเภทเนื้อหา X"

— Craig

ไม่ใช่เจ้าของภาษา แต่ไม่สนับสนุน ContentTypeเป็นตัวเลือก "ไวยากรณ์" ที่มากที่สุดหรือไม่?

— Roman Reiner

คนแรกจะต้องถูกIsSupportedContentTypeต้องตามหลักไวยากรณ์ (เว้นแต่ "ประเภทเนื้อหาสนับสนุน" ทำหน้าที่เป็นคำนามซึ่งดูเหมือนไม่น่าเป็นไปได้)

— CodesInChaos

เกี่ยวกับsupportsContentTypeอะไร ข้อความต่อไปนี้สามารถอ่านได้ทั้งหมด: if (abc.supportsContentType("text/html")). "สามารถรองรับ" หมายความว่ามีเงื่อนไขเพิ่มเติมในการรองรับประเภทเนื้อหา

— Olivier Grégoire

@WeylandYutani IsCanHasSupportCheezburger หรือไม่

— RM

คำตอบ:

106

เป็นกับ Can

ตามคำแนะนำแบบแผนการตั้งชื่อของ Microsoftทั้ง "Is" และ "Can" นั้นใช้ได้ (เช่นนั้นก็คือ "Has") เป็นส่วนนำหน้าสำหรับ Boolean

ในภาษาอังกฤษแบบธรรมดา "Is" จะถูกใช้เพื่อระบุบางสิ่งเกี่ยวกับประเภทของตัวเองไม่ใช่สิ่งที่สามารถทำได้ ตัวอย่างเช่นIsFixed, IsDerivedFrom, IsNullableทั้งหมดจะสามารถพบได้ในประเภท CLR และวิธีการ ในทุกกรณีเหล่านี้ "คือ" จะตามด้วยคำคุณศัพท์

ขณะที่ "สามารถ" ชัดเจนมากขึ้นแสดงให้เห็นความสามารถเช่นCanEdit, ,CanRead CanSeekในแต่ละกรณีเหล่านี้สามารถจะตามด้วยคำกริยา

เนื่องจาก "การสนับสนุน" เป็นคำกริยาฉันคิดว่าในกรณีของคุณCanSupportContentTypeดีกว่า

ทางเลือกที่สั้นกว่า

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

public bool Supports(System.Net.Mime.ContentType contentType)

... ซึ่งสั้นกว่าและยังคงสื่อสารวัตถุประสงค์อย่างชัดเจน คุณจะเรียกมันว่า:

ContentType contentType = new ContentType("text/plain");
var someClass = new MediatorsClass();
bool ok = someClass.Supports(contentType);

หรือประนีประนอมบางทีนี่อาจดีที่สุด:

public bool CanSupport(System.Net.Mime.ContentType contentType)

— จอห์นวู
แหล่งที่มา

เป็นเรื่องที่ดีเมื่ออ่านได้ดี:if ( someClass.Supports(contentType) )

— candied_orange

…หรือhasSupportedContentType

— Bergi

วิธีการที่เรียกว่า "CanSupports" initallty ทำให้ฉันสงสัยว่าใครใช้เวลาในการทำให้ซอฟต์แวร์สามารถรองรับกระป๋อง (เช่นเดียวกับกระป๋อง) เพียงแค่ "รองรับ" เป็นตัวเลือกที่ดีกว่าไม่ต้องสงสัยเลย!

— T. Sar - Reinstate Monica

บางครั้งนักพัฒนาซอฟต์แวร์ไม่สามารถบอกได้ว่าเมื่อใดที่ "ฟังดูแปลก" เช่นถ้าภาษาอังกฤษไม่ใช่ภาษาแรกของพวกเขา

— John Wu

บางครั้งรุ่นที่สั้นกว่านั้นแย่กว่า เช่นในห้องสมุดมาตรฐาน C ++ std::vector::empty()เรามี จากชื่อเท่านั้นมันทำให้เวกเตอร์ว่างเปล่าหรือไม่ หรือมันจะคืนค่าว่าเวกเตอร์ว่างเปล่าหรือไม่? std::vector::clear()ที่จริงหลังตั้งแต่งานในอดีตจะกระทำโดย แต่คุณต้องอ่านเอกสารโดยทั่วไปเพื่อให้แน่ใจ ในฐานะที่เป็นตัวอย่างที่ตรงข้าม Qt ของเป็นเรื่องง่ายที่จะเข้าใจในเรื่องนี้เนื่องจากวิธีการของการตรวจสอบความว่างเปล่าคือQVector QVector::isEmpty()

— Ruslan

เป็นมูลค่าการกล่าวขวัญว่าคำนำหน้า " ควร " ยังสามารถใช้ ตามแนวทางของ Appleไม่ใช่แค่ " สามารถ " และ " ควร " คำกริยาเป็นโมฆะโดยทั่วไปสามารถใช้เพื่อตั้งชื่อฟังก์ชั่นที่คืนบูลีนได้ ฉันไม่เห็นการใช้ " ประสงค์ " มากมาย แต่ " ควร " ดีสำหรับตะขอขอคำแนะนำตามที่เห็นใน reactjs:

shouldComponentUpdate: (newProps: any) => boolean

— ก่อกวน
แหล่งที่มา

ควรจะตั้งชื่อ imho น่าสงสาร "ดีก็ควรปิดเอกสาร แต่จริง ๆ แล้วฉันไม่แน่ใจ"

— Lovis

@lovis: ฉันคิดว่าความคิดเห็นของแฮร์รี่นั้นถูกต้องมาก ตัวอย่างเช่นฉันสามารถมอบหมายการดำเนินการที่เกี่ยวข้องกับฐานข้อมูลผ่านทางเลเยอร์ปลั๊กอินแต่ละปลั๊กอินมีวิธีการ "ShouldCloseConnection" ซึ่งแจ้งกรอบการทำงานว่าควรทำการล้างข้อมูลบางอย่าง เพียงแค่ตัวอย่าง แต่ "ควร" เป็นคำนำหน้าที่ถูกต้องแน่นอน

— เกอร์

@ รวมมันคลุมเครือน้อยกว่าWillCloseConnectionอย่างไร

— พื้นฐาน

@Lovis โดยทั่วไปเราใช้is...แต่ใช้should...ในการทำงานบางชื่ออาร์กิวเมนต์สถานที่ที่บูลแสดงให้เห็นสิ่งที่ทำงานควรจะเปลี่ยนสิ่งที่ หากฟังก์ชั่นสามารถเลือกที่จะปิดเอกสารเรียกพารามิเตอร์การควบคุมที่isClosedจะมีความถูกต้อง (มันไม่ได้ปิดเลย ) และเพื่อให้เราจะใช้shouldCloseเพื่อบ่งบอกว่านี่คือสิ่งที่ฟังก์ชั่นควรจะทำ (ตัวอย่างโดยพลการ; เราคงไม่มีฟังก์ชั่นเช่นนี้โดยเฉพาะอย่างยิ่งเนื่องจากการปิดเอกสารควรหนักพอที่จะมีการโทรเฉพาะ)

— KRyan

@ ขั้นพื้นฐานอย่างน้อยในกรณีของเราwill...สงวนไว้สำหรับฟังก์ชั่นอะซิงโครนัสที่ส่งคืนสัญญา ถ้าฟังก์ชั่นที่อธิบายไว้ในความคิดเห็นก่อนหน้าของฉันซิงโครนัสการใช้will...จะไม่สอดคล้องกับการตั้งชื่อของเรา

— KRyan