ข้อเสียของแท็บสต๊อปยืดหยุ่นคืออะไร [ปิด]


83

ดูที่นี่: สงครามศักดิ์สิทธิ์ทั่วไปบนแท็บ VS ช่องว่าง

ตอนนี้ดูที่นี่: tabstops ยืดหยุ่น แก้ไขปัญหาทั้งหมดแล้วและเพิ่มพฤติกรรมใหม่ ๆ ที่มีประโยชน์มากมาย

แท็บยืดหยุ่น

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

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

(ปรากฎว่ามีคำขอใน Microsoft Connect สำหรับการใช้งาน Visual Studio ของแท็บที่ยืดหยุ่นและคำขอใน Eclipseด้วยเช่นกันนอกจากนี้ยังมีคำถามที่ถามเกี่ยวกับตัวแก้ไขอื่น ๆ ที่ใช้แท็บที่ยืดหยุ่น )


4
นี่จะเป็นคำถามที่ยอดเยี่ยมสำหรับux.stackexchange.com
JonnyBoats

11
พวกเขาไม่เคยพูดถึงในการอภิปราย "แท็บกับช่องว่าง" เพราะเกือบจะไม่มีทางที่โปรแกรมเมอร์ที่ทำงานจะใช้สิ่งเหล่านี้ บางทีถ้าคุณมีการใช้ Eclipse, VS, gvim และ emacs นั่นอาจเปลี่ยนไป
พอลทอมบลิน

2
ฉันชอบความคิดนี้จริง ๆ แต่มันก็ต่อเมื่อคุณอยู่กับมันเป็นเวลาหนึ่งเดือนหรือมากกว่านั้นเพื่อที่คุณจะได้รู้ว่าข้อผิดพลาดนั้นคืออะไร เช่นเดียวกับทุกอย่างมีการรับประกันว่าจะมีบางกรณีที่ทำสิ่งที่คุณคาดไม่ถึง ...
Chris Burt-Brown

3
@ ChrisBurt-Brown มันมีความเสี่ยงเสมอใช่ IntelliSense มีข้อผิดพลาดเช่นกันเช่นการชดเชยข้อความเมื่อคุณไม่ต้องการ โดยรวมแล้ว IntelliSense ใน C # เป็นการชนะที่ยิ่งใหญ่
Roman Starkov

4
ฉันต้องการสิ่งนี้ใน notepad ++ ... ฉันต้องการสิ่งนี้ตอนนี้
Ben Brocka

คำตอบ:


32

Holy Wars เป็นเรื่องส่วนตัว

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

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

ประเด็นการนำไปปฏิบัติ

แต่เหตุผลที่ชัดเจนที่สุดเป็นเพียงอุปสรรคทางเทคนิคในการเข้า : มันเป็นแนวคิดที่แตกต่างจากสิ่งที่นำมาใช้เป็นเวลาหลายปี (ถ้าไม่ใช่ทศวรรษ) ใน IDEs และเครื่องมือแก้ไขข้อความ มันจะต้องมีการเขียนใหม่ของพวกเขาบางส่วนเพื่อประมวลผลสายในแฟชั่นที่แตกต่างกันอย่างเป็นธรรมซึ่งทำให้มันยากสำหรับระบบเก่าและใหญ่กว่าที่มีโอกาสสูงของการมีเพศสัมพันธ์ลึกและแน่นในรหัสการประมวลผลสายของพวกเขา มันเป็นอย่างไรง่ายมากที่จะทำอย่างไรเมื่อคุณเริ่มต้นจากรอยขีดข่วน (คิดว่าการสาธิตของนิคหรือของGo 's tabwriterแพคเกจ)

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

เราใส่ใจเพียงพอหรือไม่

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

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

ดังนั้นถ้าคุณต้องการให้นิคมือ


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

3
@romkyns: สำหรับหลาย ๆ สิ่งมันต้องใช้คนวงในเงียบ ๆ หรือเสียงพันเสียงกรีดร้องที่ประตู
haylem

35

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


11
และฉันก็ไม่เห็นด้วยกับความรู้สึกนี้อย่างเต็มที่เพราะกฎดังกล่าวทำให้ฉันผิดหวังเช่นกัน แต่สิ่งนี้แตกต่างกันในสองวิธี หนึ่ง: เหมือนกับแท็บสต็อปตอนนี้คุณไม่จำเป็นต้องใช้มันหากคุณไม่ต้องการ คุณสามารถปล่อยให้ข้อความของเพื่อนร่วมงานของคุณคนเดียวถ้ามันใช้พวกเขา สอง: แท็บแบบยืดหยุ่นไม่ได้มีกฎที่ซ่อนอยู่ แต่มีกฎที่ชัดเจน พฤติกรรมดังกล่าวเป็นไปตามธรรมชาติอย่างสมบูรณ์ - อาจเป็นธรรมชาติมากกว่าแท็บทั่วไปซึ่งเกิดขึ้นตามอำเภอใจโดยทั่วไปซึ่งไม่เกี่ยวข้องกับตำแหน่งภายในข้อความ นี่คือเหตุผลที่ไม่มีใครใช้ tabstops สำหรับสิ่งอื่นนอกจากการเยื้องอีกต่อไป
Timwi

10
@Timwi: คำถามคือรายการข้อบกพร่อง ฉันทำ.
mhoran_psprep

14
อาจไม่ชัดเจนจาก GIF แต่สิ่งที่เกี่ยวข้องเพียงอย่างเดียวคือเมื่อคุณกด "TAB" สิ่งที่เกิดขึ้นหลังจากนั้นจะออกมาในแนวตั้งอย่างเหมาะสม มันไม่เหมือนโปรแกรมประมวลผลคำ เพียงลองตัวอย่างการโต้ตอบที่เกิดขึ้นจริงที่ลิงค์ที่ฉันโพสต์และคุณจะเห็นว่ามันเป็นธรรมชาติ
Roman Starkov

3
@mhoran_psprep: ยุติธรรมเพียงพอฉันซาบซึ้งในความคิดเห็นของคุณ ฉันเดาว่าเรากำลังมองการตีความที่แตกต่างกันของคำถาม คุณกำลังแสดงรายการข้อเสียของตัวคุณเองในการใช้งานคุณลักษณะนี้ในขณะที่ฉันคิดว่ามันเกี่ยวกับข้อเสียของการแนะนำคุณลักษณะนี้ (เช่นทำให้ใช้งานได้และไม่บังคับ )
Timwi

27

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

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

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


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

14
@Timwi: คุณพลาดจุดที่ฉันทำไปอย่างสิ้นเชิง จะเกิดอะไรขึ้นเมื่อไฟล์โค้ดของคุณถูกวิเคราะห์โดยบางสิ่งที่ไม่ทราบถึงแท็บแบบยืดหยุ่น คุณจบลงด้วยความยุ่งเหยิงหรือพวกเขาสามารถรับมือได้หรือไม่? แล้วการควบคุมเวอร์ชันและต่างกันอย่างไร เพียงแค่หวังว่าเครื่องมือทั้งหมดสนับสนุนคุณสมบัติ $ จะไม่สมจริงแม้ว่าเครื่องมือเหล่านั้นจะเป็นโอเพ่นซอร์สก็ตาม
Sardathrion

14
@Timwi: คุณคิดว่าทุกคนพบว่าแท็บที่ยืดหยุ่นได้นั้นยอดเยี่ยมอย่างที่คุณคิด สิ่งนี้อาจไม่เป็นความจริง
Sardathrion

7
@Sathathrion ถูกต้อง จะเกิดอะไรขึ้นเมื่อฉันต้องรีโมตไปยังเซิร์ฟเวอร์ * nix ของฉันที่ไม่มีระบบหน้าต่างอยู่และต้องตรวจสอบโค้ดบางอย่างด้วย Vim / Emacs / Pico / อะไร? หากมีกลไกเพื่อให้สามารถอ่านได้ว่าจะดี ... มิฉะนั้นมันจะเป็นฝันร้าย ฉันไม่เห็นประโยชน์ของแถบยืดหยุ่นที่หยุดการใช้ประโยชน์นั้น ฉันสามารถฟอร์แมตโค้ดของฉันโดยอัตโนมัติเพื่อดูว่าควรใช้ IDE อย่างไร
Rig

7
จุดควบคุมเวอร์ชันเป็นสิ่งที่ดี - ฉันไม่คิดว่าผู้คนจะชื่นชมตัวแก้ไขที่เริ่มเปลี่ยนการจัดวาง / รูปแบบของความคิดเห็นในรหัสอย่างเงียบ ๆ ห่างจากรหัสที่พวกเขากำลังปรับเปลี่ยน (ดูหมวด magenta ในภาพเคลื่อนไหวของ OP GIF) มันจะมีประโยชน์ที่จะมีการนำการอ้างอิงมาใช้เพื่อเล่นด้วย แต่สิ่งที่ฉันเห็นจนถึงตอนนี้ไม่น่าทึ่ง - emacs ทำสิ่งนี้ไปมากแล้วด้วยการกดแป้นพิเศษสองสามครั้ง (ซึ่งเป็นสิ่งที่ดี)
mcmcc

13

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

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

แต่สำหรับอดีตฉันมักจะเยื้องข้อโต้แย้งทั้งหมดโดยหนึ่งระดับเพิ่มเติมและที่ทำงานได้ดีกับฉันทั้งหมด:

void foo(
    int x,
    int y,
    string z
)

และฉันไม่เห็นความต้องการที่จะเปลี่ยนแปลงสิ่งนั้น

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

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

หากผู้แก้ไขใช้พวกเขาฉันก็จะไม่ใช้มัน


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

1
@romkyns เราได้พูดคุยเกี่ยวกับเรื่องนั้นและในช่วงเวลาหนึ่งฉันพยายามใช้ฟอนต์แบบสัดส่วนสำหรับการเขียนโปรแกรมในบางครั้ง ผลที่สุดคือการที่ตัวอักษร monospaced ทำงานได้ดีขึ้นแม้ว่าจะไม่สนใจการเยื้อง นอกจากนี้ฉันกำลังทำงานเฉพาะใน Vim และคอนโซลซึ่งไม่น่าจะสนับสนุนฟอนต์ตามสัดส่วนได้ทั้งหมด
Konrad Rudolph

1
@romkyns ที่กล่าวว่าปัญหาเหล่านี้สามารถแก้ไขได้ (หรืออาจแก้ไขได้ด้วยตัวอักษรตามสัดส่วนที่ออกแบบมาสำหรับการเขียนโปรแกรม) แต่ฉันก็ยังไม่เห็นความจำเป็นจริงๆ
Konrad Rudolph

13

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

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

สิ่งที่ฉันต้องการ:

def foo( bar,
         xyzzy ):
    wibble()

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


ตกลง การใช้งานของ Nick ไม่ได้ผลกับภาษาอย่าง Python
Roman Starkov

3
ทำไมถึงไม่ได้ผล นี่ไม่ใช่ข้อ จำกัด พื้นฐานอัลกอริทึมก็ต้องรู้ภาษา แต่ในระดับนี้สิ่งนี้เป็นความจริงแม้กระทั่งทุกวันนี้ Vim จะกำหนดกฎการเยื้องต่างกันขึ้นอยู่กับภาษา สิ่งนี้สามารถรองรับการย่อหน้าของ Python ได้อย่างง่ายดาย
Konrad Rudolph

1
@ KonradRudolph ไม่พวกเขาทำไม่ได้ การดึงแท็บแบบยืดหยุ่นคือความสามารถในการเยื้อง / รวมกลุ่มข้อความเข้าด้วยกันโดยอัตโนมัติ ตัวอย่างหนึ่งก็คือจุดสิ้นสุดของคำสั่ง "if": คุณลองและไม่เยื้องเพราะคุณออกจากคำสั่ง แต่แท็บที่ยืดหยุ่น "สมาร์ท" ตัดสินใจว่าคุณหมายถึงการยกเลิกการเยื้องบรรทัดหรือสองข้างบนเป็นต้น และอื่น ๆ ... และถ้าคุณต้องจัดกลุ่มข้อความด้วยกันอย่างชัดเจนแล้ว - ประเด็นคืออะไร? มันเป็นงานที่ต้องทำมากกว่าที่แก้ไขเยื้องด้วยตัวคุณเอง ...
Izkata

1
@Izkata Unindenting ด้วยตนเองจะ (ควร) เพียงแค่จบกลุ่มปัจจุบัน ทำไมคุณถึงต้องควบคุมการเยื้องด้วยแท็บยางยืดด้วยตนเองหยุด? คุณจะไม่ทำเช่นนั้นอัลกอริทึมรู้ว่าเมื่อคุณทำมันก็คือการจบบล็อกไม่ได้เยื้องบล็อกข้างต้น
Konrad Rudolph

1
โอ้จุดดี อืม ... บางทีคุณอาจเยื้องการโต้เถียงได้ ดังนั้นwibble()จะมีการเยื้องเพียงครั้งเดียวดังนั้นจึงไม่สอดคล้องกับอาร์กิวเมนต์ของฟังก์ชัน?
Ajedi32

12

ทำไมเราไม่สร้างอักขระแท็บแนวตั้ง (VT, ASCII 11) เพื่อแสดงการใช้แท็บแบบยืดหยุ่นได้? มันไม่มีจุดประสงค์ในการเขียนโปรแกรมภาษากระแสหลัก แต่ยังแยกวิเคราะห์เป็นช่องว่างที่ถูกต้องในพวกเขาทั้งหมด AFAIK

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

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


10

ไม่ได้กล่าวถึงเนื่องจากไม่ได้ใช้งานใน IDEs ส่วนใหญ่ของโปรแกรมแก้ไขข้อความ มันเป็นความแปลกใหม่ของการใช้งานจริงเพียงเล็กน้อยในโครงการ

Spaces ถูกนำมาใช้เพื่อเขียนโปรแกรมตั้งแต่สมัยของการ์ดเจาะ แท็บเข้ามาและบางคนคิดว่าพวกเขาเป็นความคิดที่ดีอย่างชัดเจน (พวกเขาเข้าใจผิด: p)

ในวันที่ผู้แก้ไขที่ทันสมัยที่สุดสามารถแปลงแท็บเป็นช่องว่างโดยอัตโนมัติ ... พวกเขาไม่มีจุดหมายอย่างเป็นธรรม

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


ฉันได้ลบความคิดเห็นขณะที่พวกเขากำลังดูถูกเหยียดหยาม
ChrisF

1
แค่คิดว่าฉันชี้ให้เห็นเหตุผลหลักว่าทำไมฉันชอบความคิดของแท็บยืดหยุ่นไม่ได้เพราะมันแก้ปัญหาแท็บเทียบกับช่องว่าง แต่เพราะพฤติกรรมที่แสดงใน GIF ในคำถามเดิม; การจัดตำแหน่งอัตโนมัติที่ปราศจากความเจ็บปวด ยิ่งไปกว่านั้นสำหรับ VCS ต่างมีประโยชน์เพิ่มเติมที่ไม่มีการเปลี่ยนแปลงช่องว่างในตัวอย่างนั้น
Ajedi32

"ต้องติดตั้งเครื่องมืออื่น ... " ไม่ใช่ข้อโต้แย้งที่ดีพอ ... ราวกับว่ามีเครื่องมือที่ใช้ไม่เพียงพออยู่แล้ว
Milind R

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

ทัศนคติเช่นนี้เป็นเหตุผลว่าทำไม บริษัท อย่าง MS ตัดสินใจบังคับให้ผู้ใช้เข้าสู่ UXes ใหม่ ... ฉันครุ่นคิดถึงสิ่งที่จะเกิดขึ้นถ้าทัศนคติเดียวกันนี้ถูกนำไปใช้กับฟลอปปี -> การเปลี่ยนแผ่นซีดี
Milind R

4

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

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

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

ฉันคิดว่าฉันชอบความคิดที่ว่า 'แท็บแท็บ' ที่ส่วนท้ายของบรรทัดยืดความคิดเห็นบล็อกและบรรทัดขึ้นความคิดเห็นทั้งหมดในบรรทัดต่อมา (ที่มีระยะห่างสองแท็บ) ตามลำดับ


3

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

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

แต่นั่นไม่ได้หมายความว่าจะไม่สามารถปรับใช้ฟีเจอร์นี้เพิ่มเติมได้ ภาษาการเขียนโปรแกรมทุกภาษาถูกนำมาใช้เพิ่มขึ้นเรื่อย ๆ แม้ว่าทั้งทีมต้องการคอมไพเลอร์ใหม่และ IDE ใหม่เพื่อเริ่มใช้งาน เช่นเดียวกับสถาปัตยกรรมฮาร์ดแวร์ทุกตัวและตัวอย่างอื่น ๆ อีกมากมาย ไม่ใช่กรณีที่การขาดการรวมเข้ากับเครื่องมือที่มีอยู่นั้นเป็น show-stopper: สิ่งนี้เป็นจริงตัวอย่างเช่น“ unified-diff format” ซึ่งแทนที่รูปแบบที่อ่านได้น้อยกว่าก่อนหน้าซึ่งไม่สามารถเข้าใจได้โดยเครื่องมืออัตโนมัติ (เช่นแพทช์) เครื่องมือเหล่านั้นได้รับการอัพเกรดเมื่อเวลาผ่านไป

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


อาร์กิวเมนต์ C vs C ++ ปรากฏเข้าใจผิดเล็กน้อย แม้ว่าอาจเป็นเรื่องจริงสำหรับ "บางคน" (ตามที่คุณพูดอย่างถูกต้อง) แต่ก็มีเหตุผลที่ชัดเจนที่จะติดกับ C หรือชอบ C ++ ขึ้นอยู่กับสถานการณ์ ขนาดของ C ++ runtime เป็นขนาดใดขนาดหนึ่งในการตั้งค่าเริ่มต้น
haylem

ฉันอยู่กับเฮย์เล็ม ประเด็นของคุณน่าจะดีกว่านี้หากไม่มีการเปรียบเทียบ C-vs-C ++ พวกเขาเป็นภาษาที่แตกต่างกันมาก ในใจของฉัน C สำหรับการเขียนโปรแกรมระบบและงานระดับต่ำอื่น ๆ ที่คุณต้องการการควบคุมจำนวนมาก (เช่น VM) C ++ มีประโยชน์มากกว่าสำหรับแอปพลิเคชันระดับกลางที่นามธรรมมีประโยชน์ในการจัดการความซับซ้อน (เนมสเปซ, คอนเทนเนอร์ STL และอัลกอริทึม, แม่แบบ) แต่ประสิทธิภาพยังคงเป็นปัญหา (เกมเป็นตัวอย่างที่เห็นได้ชัดที่สุด)
Jon Purdy

@ Haylem: ขอบคุณสำหรับความคิดเห็น ฉันได้ลบการอ้างอิงถึง C / C ++
Timwi

@ JonPurdy: ขอบคุณสำหรับข้อเสนอแนะ ฉันได้ลบการอ้างอิงถึง C / C ++
Timwi

2

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

โดยรวมแล้วฉันคิดว่ามันเป็นความคิดที่ดี แต่โดยส่วนตัวฉันไม่ชอบมัน


1

ฉันเพิ่งลองใช้การแท็บแบบยืดหยุ่นของ jEdit ซึ่งทำงานได้ดีกับภาษาการเขียนโปรแกรมที่ฉันคุ้นเคย (ภาษา HTML / XML และ C-like เป็นหลัก) ด้วยรหัส Python นี่คือวิธีการแสดงผล (ช่องว่างที่ใช้แทนแท็บเพื่อแสดงให้เห็นว่าสิ่งต่าง ๆ เรียงกัน):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

สำหรับภาษาอย่าง Python ที่ต้องพึ่งพาการเว้นวรรคนี่เป็นดีลเลอร์เบรกเกอร์จนกว่าคุณจะปิดการใช้งานฟังก์ชั่นที่มีให้โดยแท็บยืดหยุ่น บรรณาธิการอย่าง Vim และ Emacs จะทำการปิดการใช้งานฟังก์ชั่นส่วนใหญ่อย่างง่าย ๆ หากคุณรู้ชื่อของตัวเลือกและวิธีการปิดการใช้งาน แต่ฟังก์ชั่นนี้จะต้องถูกปิดใช้งานสำหรับรหัสเช่นด้านบน

ที่ถูกกล่าวว่ามันยอดเยี่ยมสำหรับ x86 ASM, C, C ++, Go, XML, HTML และอื่น ๆ ที่ไม่พึ่งพาช่องว่างมาก:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

ฉันจะบอกว่าภาษา Lisp เช่น Scheme มีแบบแผนของตัวเองที่จะทำให้แท็บที่ยืดหยุ่นแสดงโค้ด "น่าเกลียด" ถ้าฉันเปลี่ยนการตั้งค่า tabstop ของฉันให้ตรงกับแบบแผนของ 2 คอลัมน์และแทรก tabstops ในตำแหน่งที่ผิดปกติ (ระหว่างฟังก์ชันและอาร์กิวเมนต์):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

เทียบกับที่อ่านได้มากขึ้น:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

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


0

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

คุณสามารถให้ Emacs จัดความคิดเห็นได้เช่นกันโดยไม่มีปัญหามาก แต่ AFAIK ไม่มีใคร แต่คุณต้องการ


2
ฉันสามารถตีความประโยคสุดท้ายของคุณว่าเป็นการหลอกเพราะเห็นได้ชัดว่ามีชายอีกคนหนึ่งที่ต้องการให้มันค่อนข้างแย่มากพอที่จะสร้างเพจที่มีการถกเถียงกันดีการใช้จาวาและ GIF เพื่อแสดงว่าทำไมมันถึงดี หากคุณอ่านคำตอบคุณจะพบว่า Nick ไม่ได้อยู่คนเดียว เดี๋ยวก่อนดูที่นี่ด้วย
Roman Starkov

โดยวิธีการที่ Emacs จะเยื้องอีกครั้งในwilmaขณะที่คุณทำการแก้ไขเช่นการเปลี่ยนความยาวของชื่อฟังก์ชั่น? ถ้าเป็นเช่นนั้นนั่นเป็นสิ่งที่ค่อนข้างใกล้เคียงกับแท็บที่ยืดหยุ่นได้
Roman Starkov

@romkyns: ฉันไม่ได้ตั้งใจจะหมุนรอบฉันแค่หมายความว่าฉันไม่เคยเห็นรูปแบบของความคิดเห็นที่เยื้องเข้าไปใน EMACS โดยทั่วไป EMACS จะไม่เยื้องบรรทัดหลายบรรทัดในขณะที่คุณพิมพ์ แต่อาจมีการเปลี่ยนแปลงได้เช่นกัน
วินไคลน์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.