Bố cục bàn phím lý tưởng cho lập trình [đã đóng]


87

Tôi thường nghe thấy những lời phàn nàn rằng các ngôn ngữ lập trình sử dụng nhiều ký hiệu cho ngắn gọn, đáng chú ý nhất là C và C ++ (tôi sẽ không đụng đến APL), rất khó nhập vì chúng yêu cầu sử dụng phím shift thường xuyên. Một hoặc hai năm trước, tôi cảm thấy mệt mỏi với nó, tải xuống Trình tạo bố cục bàn phím của Microsoft , thực hiện một vài thay đổi đối với bố cục của mình và chưa một lần nhìn lại. Sự khác biệt về tốc độ là đáng kinh ngạc; với một vài thay đổi đơn giản này, tôi có thể gõ mã C ++ nhanh hơn khoảng 30%, tất nhiên tùy thuộc vào độ rậm rạp của nó; trên hết, tốc độ đánh máy của tôi trong văn bản đang chạy thông thường không bị ảnh hưởng.

Các câu hỏi của tôi là: bố cục bàn phím thay thế nào đã tồn tại cho lập trình, đã trở nên phổ biến, có bố cục nào vẫn được sử dụng hiện đại không, cá nhân bạn có sử dụng bố cục đã thay đổi nào không và bố cục của tôi có thể được tối ưu hóa hơn nữa như thế nào?

Tôi đã thực hiện các thay đổi sau đối với bố cục QWERTY tiêu chuẩn. (Tôi không sử dụng Dvorak , nhưng có một bố cục Dvorak lập trình viên đáng được đề cập.)

  • Hoán đổi số bằng các ký hiệu ở hàng trên cùng, vì các số dài hoặc lặp lại theo nghĩa đen thường được thay thế bằng các hằng số được đặt tên;
  • Hoán đổi backquote bằng dấu ngã, bởi vì backquote rất hiếm trong nhiều ngôn ngữ nhưng các hàm hủy lại phổ biến trong C ++;
  • Hoán đổi dấu trừ với dấu gạch dưới, vì dấu gạch dưới phổ biến trong các số nhận dạng;
  • Hoán đổi dấu ngoặc nhọn với dấu ngoặc vuông, vì các khối phổ biến hơn các chỉ số dưới; và
  • Hoán đổi dấu ngoặc kép với dấu nháy đơn, vì chuỗi ký tự phổ biến hơn ký tự.

Tôi nghi ngờ điều cuối cùng này có lẽ sẽ gây tranh cãi nhất, vì nó gây trở ngại nhiều nhất cho việc chạy văn bản bằng cách yêu cầu sử dụng phím shift để nhập các co thắt phổ biến. Bố cục này đã tăng đáng kể tốc độ đánh máy của tôi trong C ++, C, Java và Perl, đồng thời tăng phần nào trong LISP và Python.


32
Có lẽ chỉ là tôi suy nghĩ quá chậm - nhưng tốc độ gõ thô thường không phải là yếu tố hạn chế của tôi khi phát triển phần mềm. Nếu đúng như vậy, có lẽ tôi sẽ nghĩ rằng mình đang làm sai.
Lucero

9
@Lucero: Nhìn chung , không, nhưng khi tôi (cuối cùng!) Đã tìm ra những gì tôi nên làm, tôi có thể gõ càng nhanh và thoải mái thì càng tốt. Một khi bạn đã làm tất cả suy nghĩ cứng của bạn, đôi khi đó chỉ là một rất nhiều mã mài để làm ... :-)
TJ Crowder

3
@Jon: Thực sự khuyên bạn nên biến nó thành CW trước khi nó bị đóng cửa vì chủ quan (suy cho cùng là như vậy).
TJ Crowder

20
@TJ: làm CW. Một bố cục tốt không phải là vấn đề của hiệu suất thô vì nó là một trong những sự thoải mái - nhưng sự thoải mái là rất quan trọng đối với hiệu suất.
Jon Purdy

3
Thật buồn cười khi bạn bị khá nhiều người nói xấu, tôi khuyên bạn nên bỏ qua họ. Không chỉ tốc độ đánh máy ( một yếu tố nếu bạn có thể gõ đủ để có thể "lập trình như bạn nghĩ"), công thái học vượt trội hơn điều đó. Nhưng tốc độ và công thái học đi đôi với nhau: các động tác làm căng tay của bạn sẽ chậm thực hiện, mệt mỏi dẫn đến sai sót và việc sửa các khoản thuế đó khiến tay bạn thậm chí còn nhiều hơn. Và về lâu dài, việc điều chỉnh bố cục bàn phím để phù hợp với nhu cầu của bạn có thể là sự khác biệt giữa RSI hoặc không RSI.
just somebody

Câu trả lời:


30

Tôi vẫn cho rằng tốc độ đánh máy không phải là yếu tố chính trong thời gian hoàn thành một dự án. Nếu đúng như vậy thì có một vấn đề lớn (Hàng tuần viết mã giúp chúng tôi tiết kiệm hàng giờ lập kế hoạch).

Về câu hỏi của bạn, tôi thích sử dụng bố cục tiêu chuẩn hơn vì nó có nghĩa là tôi không phải dành 10 phút đầu tiên trông ngu ngốc khi được trình bày với bố cục bàn phím tiêu chuẩn.

Một số thay thế bạn đã đề xuất, ví dụ như hàng trên cùng với các ký tự đặc biệt không tạo ra một chút khác biệt nào vì mặt khác, ngón tay bên ngoài sẽ di chuyển để thay đổi cùng một lúc.

IMHO Một điều giúp ích cho các bố cục chuỗi ở trên là chỉ sử dụng các phím tắt. Vim và Emacs được khuyến khích. Nó làm cho văn bản di chuyển xung quanh nhanh hơn.


20
Ồ, không, tốc độ gõ không phải là một điểm nghẽn, nhưng đồng thời, tại sao lại để một thứ ngớ ngẩn như bàn phím cản đường bạn? Tôi đã không gặp khó khăn khi chuyển đổi qua lại giữa bố cục của mình và những bố cục khác, bởi vì tôi sử dụng cả hai thường xuyên; Tôi chỉ đơn giản thích của tôi hơn. Và tôi phải thừa nhận rằng, emacs làm cho việc lập trình nhanh nhất có thể — khi tôi không phải tra cứu một chuỗi khóa.
Jon Purdy

4
Ồ, sự đồng thời của các chuyển động tay trái và tay phải cũng không tạo ra sự khác biệt: bộ điều chỉnh vẫn phải được nhấn xuống trước khi phím được gõ. Chênh lệch mili giây, chắc chắn là vậy, nhưng một lần nữa, tại sao lại cản trở chính bạn? Lập trình với bố cục không phù hợp với bạn cũng giống như lập trình trên bàn phím dính.
Jon Purdy

6
Tôi duy trì điều đó bằng cách lưu giữ một số bố cục bàn phím trong bộ nhớ, bạn đang phá hoại bộ nhớ cơ của bạn và do đó làm cho việc nhập liệu của bạn chậm hơn.
JesperE

1
Một vấn đề khác với phím shift là các chuỗi mà bạn đang xen kẽ, vì vậy cả hai tay đều nhảy từ hàng trên cùng sang phím shift và quay lại. Tuy nhiên, tôi không nói rằng nó đủ phổ biến để lo lắng, nhưng những thứ như "(! * X)" có thể đủ điều kiện để gây khó chịu.
Steve314,

1
-1: Không đóng góp gì cho cuộc thảo luận (lập luận "trông ngu ngốc" không được hỗ trợ bởi dù chỉ một dữ liệu từ kinh nghiệm, đó là một nỗi lo về tương lai) và không thể sửa được.
Evgeni Sergeev

16

Tôi sẽ tiếp cận câu hỏi của bạn theo cách sau. Nhiệm vụ là tổ chức bàn phím sao cho giảm thiểu các hành trình phím và chuyển động của bàn tay cho văn bản nhất định.

Các bước hướng tới một giải pháp khả thi. Tạo một chương trình:

  1. Lấy một tệp văn bản với mã nguồn. (Càng lớn càng tốt và từ nhiều nguồn khác nhau!)
  2. Đếm tần suất sử dụng của mỗi biểu tượng (sự hiện diện của nó trong văn bản).
  3. (tùy chọn) Dựa trên bước 2: Chương trình tạo số hành trình phím cho mỗi biểu tượng cộng với khoảng cách tay phải đi từ vị trí trung tâm. Kết quả là bạn sẽ có một thước đo mức độ hiệu quả của bố cục bàn phím.

Bây giờ thủ công hoặc bằng cách viết một chương trình Xác định lại bố cục của bạn theo cách sau. Đặt biểu tượng thường được sử dụng nhất ở vị trí trung tâm gần với bàn tay mạnh mẽ của bạn. Biểu tượng thứ hai chuyển đến tay yếu của bạn ở vị trí trung tâm. Biểu tượng thứ ba quay trở lại bàn tay mạnh mẽ của bạn ... và cứ thế. Sau đó, bạn dần dần di chuyển từ vị trí trung tâm của bàn tay sang các khu vực "xa" hơn của bàn phím. Khi tất cả bàn phím đã đầy thì bạn tiếp tục quá trình gán các phím nhưng lần này là nhấn phím Shift. Sự khác biệt khác sẽ là bạn không xoay bàn tay mạnh và yếu cho từng biểu tượng khi Shift giảm. Với phím shift xuống trước tiên, bạn sẽ điền vào các vị trí trung tâm trên bàn phím và sau đó di chuyển đến các vị trí xa hơn.

Khi bạn thực hiện tất cả những điều đó, hãy thực hiện lại bước 3 cho bố cục mới để xem bố cục đã được cải thiện như thế nào.

Bạn có thể phải mang theo bàn phím của mình mọi lúc. Về mặt sáng sủa, không ai sẽ chạm vào máy tính của bạn. Nó sẽ làm cho bạn trông giống như một Pro.

Cuối cùng, đừng quên chia sẻ những phát hiện của bạn.


Tôi thực sự thích câu trả lời này
,:

13

Tôi đang chơi với một biến thể của bố cục Colemak vào lúc này với những thay đổi lớn về biểu tượng:

không có SHIFT:

`- {} []; <> () _ =
qwfpgjluy * / # \
arstdhneio '
zxcvbkm ,. !

với SHIFT:

~ 1 2 3 4 5 6 7 8 9 0 & +
QWFPGJLUY @ ^ $ |
ARSTDHNEIO "
ZXCVBKM% :?

Có lẽ tôi sẽ khôi phục khóa / ...

Nhưng điều này không dựa trên bất kỳ nghiên cứu âm thanh nào và tôi cũng muốn thấy một bố cục được tối ưu hóa (Tối ưu hóa bao gồm những thứ như sửa đổi thủ công, v.v., cũng như bảo quản ZXCV, ...) với kho ngữ liệu dựa trên mã nguồn, bởi vì tất cả các bố cục này dường như chỉ được tối ưu hóa cho văn xuôi. Ví dụ, 'f' là một chữ cái rất phổ biến trong C (if, for).

Cập nhật: Tôi hiện đang sử dụng

`- {} [] @ <> () _ =
qwkrgyulp *; #
asftdhneio '\
\ zxcvbjm ,. /

với SHIFT:

~ 1 2 3 4 5 6 7 8 9 0 ^ +
QWKRGYULP &! $
ASFTDHNEIO "|
| ZXCVBJM% :?

Điều này dựa trên tối ưu hóa từng phần 6 phím-hoán đổi được lấy từ Carpalx với việc bảo toàn các phím tắt Cắt / Sao chép / Dán / Hoàn tác thông thường và được sửa đổi để có quyền truy cập tốt hơn vào các ký tự lập trình thông thường.


1
Tôi thích ý tưởng làm cho các ký tự mặc định trên các số. tức là: shift + 1 để lấy một cái, và nhấn phím 1 cho bạn!
Ray

12

Tạo một trình ghi phím đơn giản, sau đó đếm số lần mỗi phím được nhấn. Chạy nó trong một hoặc hai ngày, sau đó lưu đầu ra vào tệp văn bản. Làm điều này một lần và một lúc. Không quan trọng bạn đang sử dụng bố cục nào, vì bạn chỉ nhìn thấy phím nào đang được sử dụng nhiều nhất.

Nếu bạn muốn có một bố cục tốt, bạn không thể ngại đi ra khỏi quy chuẩn. Tôi khuyên bạn nên đặt 11 phím trên cùng dọc theo hàng chính, sau đó 11 phím trên cùng tiếp theo làm hàng trên cùng (để lại 2 phím phía trên phím quay lại là các phím ít được sử dụng nhất), sau đó là 11 phím trên cùng thứ 3 làm hàng dưới cùng . Bây giờ sẽ còn lại 4 chìa khóa. Lấy chúng và đặt chúng vào các vị trí - = và] \. Chúc mừng! Bây giờ bạn đã tạo một bố cục bàn phím tuyệt vời cho mục đích của mình! = D


1
Câu trả lời rất hay: bàn phím phải được viết tay cho chủ sở hữu
Julien__

1
Đối với thống kê sử dụng bàn phím, có những chương trình đã tốt có thể hiển thị một bản đồ nhiệt, như thế này: WhatPulse
Mihai Matei

[Ghé thăm các bình luận của bài viết cũ] Đó thực sự là một ý tưởng thực sự hay (hoặc nóng;]). Tôi sẽ phải tự mình kiểm tra điều đó!
Tgwizman

9

Nhìn chung, tôi nghĩ rằng có một trình soạn thảo văn bản tốt và biết cách sử dụng nó sẽ tốt hơn là cố gắng cải thiện tốc độ đánh máy của bạn. Có thể ghi và phát lại macro đôi khi là một cứu cánh và việc lựa chọn các đoạn mã được gán phím tắt có thể hữu ích vì thông thường có giới hạn do ngôn ngữ đặt ra đối với những gì có thể được chuyển thành thư viện.

Nói chung hơn, tôi nghĩ rằng những công cụ nâng cao năng suất thực sự là tất cả về kiến ​​thức ...

  • Biết những công cụ và thư viện có sẵn và cách sử dụng chúng.
  • Biết cấu trúc tổng thể của mã bạn đang làm việc, không chỉ một chút của bạn.
  • Biết các thuật toán chính, các mẫu thiết kế và thành ngữ để bạn không cần phải phát minh lại chúng.
  • Biết rõ các quy tắc để bạn có thể linh hoạt - bạn biết khi nào nên phá vỡ chúng.
  • Biết đồng nghiệp của bạn và điểm mạnh, điểm yếu của họ, v.v. - tức là biết khi nào cần tìm ra điều gì đó cho bản thân, cũng như khi nào và hỏi ai.

FWIW, tôi không tuyên bố mình mạnh về tất cả những thứ đó. Tôi luôn quá cố gắng trong việc tự mình giải quyết các vấn đề và có xu hướng quá mạnh mẽ đối với việc sáng tạo lại bánh xe và các phương án kiến ​​trúc vĩ đại.

Dù sao, tôi chỉ nghi ngờ rằng thời gian dành cho việc thay đổi và tìm hiểu bố cục bàn phím sẽ khiến bạn phân tâm khỏi những vấn đề quan trọng hơn.


Tôi đồng ý với bạn về tất cả các tính! Sử dụng tốt các công cụ và thành ngữ chỉ là lập trình tốt. Nhưng đây là một câu hỏi về một điều rất cụ thể, và này, mười lăm phút hai năm trước đã giúp tôi tiết kiệm được một lượng thất vọng đáng kể kể từ đó.
Jon Purdy

@Jon - Tôi hiểu ý, nhưng tôi nghĩ thói quen đánh máy của tôi hiện đã được lập trình khá mạnh - thay đổi sẽ là một công việc khó khăn.
Steve314

-1: Không giống như nó dựa trên kinh nghiệm với các bố cục bàn phím thay thế; đi ngược lại kinh nghiệm của tôi với họ. Các cử chỉ vượt ra ngoài chủ đề. Không cung cấp các mục hành động cụ thể. Không sửa được.
Evgeni Sergeev

-5

Thay đổi bố cục bàn phím là một ý tưởng tồi vì nó (có thể) sẽ tăng tốc độ gõ của bạn trên một bàn phím, nhưng lại làm hỏng tốc độ gõ của bạn trên các bàn phím khác hoặc trên máy tính mà bạn không có bố cục bàn phím đặc biệt của mình. Tôi thấy rằng tốt hơn hết là bạn nên điều chỉnh bản thân theo các giá trị mặc định, tức là bạn phải thay đổi chúng ở mọi nơi. (Cá nhân tôi, các ngón tay của tôi thiên về Emacs, điều này gây ra nhiều va chạm khi gõ ở mọi nơi khác.)


6
Tôi vui vẻ chuyển đổi giữa hai bố cục. Jon báo cáo đã "một hoặc hai năm" và anh ấy không gặp khó khăn gì khi quay lại. Về cơ bản, YMMV.
TJ Crowder

4
Tôi thấy việc thay đổi giữa bàn phím và bố cục bàn phím dễ / khó như thay đổi giữa việc nói bằng các ngôn ngữ khác nhau - nếu bạn biết rõ chúng, sau vài phút bạn sẽ lấy lại tốc độ suy nghĩ hoàn toàn.
liori

1
@liori: cũng nói rồi, mặc dù theo thứ tự phút hay giây thì hoàn toàn phụ thuộc vào mức độ mệt mỏi của tôi. : P
Jon Purdy

1
@liori "sau vài phút ..." Có vẻ như các công ty và quốc gia (đa quốc gia) chuẩn hóa ngôn ngữ cho một vài mục đích. 1) Tốc độ giao tiếp. 2) tính chính xác của giao tiếp. Tôi nghi ngờ việc chuẩn hóa bố cục bàn phím sẽ thấy những lợi ích tương tự.
Jason D

2
@Jason D: Điểm hợp lệ, nhưng tôi rất vui vì chúng không áp dụng cho tôi ... Tôi hiếm khi sử dụng máy tính của người khác.
liori
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.