Touch typing para sa mga programmer: mga simbolo, numero at ang bilis na mahalaga

Bakit mahinang panukat ng pag-type ng code ang WPM sa prosa

Sa tatlong paraan naiiba ang code sa teksto, at wala ni isa sa mga ito ang nasusukat ng typing test na binuo mula sa mga karaniwang salitang Ingles.

Ang una ay ang halo ng mga karakter. Binilang namin. Sa unang sampung post sa blog na ito, mga 93 sa bawat 100 karakter na hindi space ay titik, 5 ay bantas at 2 ay digit. Sa JavaScript source ng command-line tool ng npm, bumababa ang titik sa mga 80 at tumataas ang simbolo sa 19. Lumalabas sa 80 hanggang 85 na titik ang json at email module ng Python, at sa 64 ang isang siksik na build script namin, na isang-katlo ng mga karakter ay simbolo. Kaya humigit-kumulang tatlo hanggang pitong beses na mas maraming simbolo ang code kaysa sa aming prosa. Karamihan sa mga ito ay nasa top row o nangangailangan ng Shift, ibig sabihin ay ang kanang hinliliit at ang mas mahihinang abot. Binuo ang aming mga test sa salitang Ingles mula sa 1,000 pinakakaraniwang salita sa isang corpus ng subtitle; wala roon ang "{".

Ang ikalawa ay ritmo. Tina-type ang prosa nang tuloy-tuloy at mahaba. Tina-type ang code sa maiikling bugso sa pagitan ng mga paghinto para mag-isip, mag-scroll at magbasa. Ang mga boluntaryo sa pag-aaral nina Dhakal et al. noong 2018 sa 136 milyong keystroke, na kumokopya ng mga pangungusap, ay nag-average ng mga 239 ms sa pagitan ng mga key. Puno ng mga puwang na ilang segundo ang araw ng isang programmer, at mas mahalaga ang bilis ng bugso sa loob ng maiikling takbo kaysa sa anumang average.

Ang ikatlo ay ang editor. Dahil sa autocomplete, snippet at keyboard shortcut, maliit na bahagi lang ng mga karakter sa screen ang talagang tina-type ng nagtatrabahong programmer. Walang typing test na makakasukat niyan, at hindi nagkukunwari ang sa amin.

Mahalaga ba ang typing speed sa programming?

Mas kaunti kaysa sa inaakala ng mga tao, at sa ibang lugar. Kapag may nagtanong kung sapat ang 60 WPM para maging programmer, oo ang sagot, may kondisyon: kung tumitingin ka pababa para sa mga simbolo at numero, hindi 60 WPM ang bilis mo sa pag-type ng code. Mas mahalaga kaysa sa hilaw na bilis ang kakayahang mag-type ng isang linya nang hindi napuputol ang daloy ng iniisip mo, at ang pagtingin pababa sa keyboard ang pumuputol dito.

Paano mag-type ng mga simbolo nang mas mabilis, at bakit walang nagtuturo nito

Isang tanong na paulit-ulit na lumalabas sa mga typing forum: kaya ng isang tao na mag-touch type ng mga titik sa disenteng bilis, pero sa sandaling magsimula siyang mag-code, bumabalik siya sa paghahanap ng mga simbolo, numero at kahit malalaking titik, at gusto niya ng unti-unting paraan para matutunan ang mga iyon, gaya ng pagkatuto niya sa mga titik, ilang key sa isang pagkakataon.

Bahagi ng nagpapahirap sa mga simbolo ang Shift. Sa npm source na binilang namin, mga 45% ng mga keystroke ng simbolo ay mga karakter na naka-Shift gaya ng ( ) { } : at $, malapit sa 9 sa bawat 100 karakter na hindi space bago mo pa bilangin ang kahit isang malaking titik. Kaya ayusin muna ang ugali sa Shift: pindutin ang Shift gamit ang kamay na hindi nagta-type ng karakter. Nasa 9 at 0 ng kanang kamay ang ( at ), kaya kaliwang Shift ang gamit nila; nasa kaliwang kamay ang ! @ # $, kaya kanang Shift ang gamit nila. Karamihan ng natutong mag-type nang mag-isa ay kaliwang Shift ang ginagamit sa lahat, at para sa ! ay pinipilit nito ang kaliwang hinliliit na pumindot ng dalawang key nang sabay. Alamin ang sarili mong ugali sa pag-type ng linyang may @ at $ at pagmasdan kung aling hinliliit ang gumagalaw.

Mahirap sanayin nang hiwalay ang mga simbolo at nakakabagot pa itong sanayin: kasama ng mga salita ang mga titik, kasama ng code ang mga bracket, at hindi kawili-wili ang random na code. Ang sagot namin ay sanayin ang mga simbolo sa totoong mga linya ng code, isang klase sa isang pagkakataon.

Isang klase sa isang pagkakataon

Ito ang pagkakasunod-sunod na gagamitin namin, at ang pagkakasunod-sunod ng symbol track na ginagawa namin para sa pahina ng pagsasanay. Hangga't hindi pa ito lumalabas, magagawa mo rin ito sa pamamagitan ng pagdidikit ng totoong code sa custom mode, isang klase ng simbolo sa isang pagkakataon, at hindi pagdaragdag ng susunod na klase hangga't hindi nasa 95% na katumpakan ang kasalukuyan:

• Mga digit. Ang number row, kung saan umaabot pataas ang mga daliri sa home row. Ito ang nauuna dahil ito ang pinakaginagamit na klaseng hindi titik at dahil halos lahat ay may masamang ugali rito, gaya ng hintuturo na gumagawa ng 4, 5, 6 at 7. Mabilis na pagsusuri ang numbers test.
• Mga bracket bilang pares. ( ) muna, pagkatapos [ ], pagkatapos { }. Pares, dahil halos hindi mo kailanman tina-type ang isa nang wala ang isa pa: sa npm source na iyon, 6,195 beses lumalabas ang ( at 6,194 ang ). Ang pagsasanay sa galaw ng pagbukas at pagsara bilang iisang yunit ang nagpapabilis dito. Sa pansarang bracket napuputol ang ritmo ng karamihan.
• Mga operator. = + - * / at ang mga angle bracket, pati ang mga pinagsamang anyo (==, =>, +=, !=). Nakakalat ang mga ito sa number row at sa mga key ng bantas sa kanang kamay, at ilan ang nangangailangan ng Shift sa parehong kamay, na siyang nakakailang na bahagi.
• Mga panipi at bantas. ' " ; : , . na ang kanang hinliliit ang gumagawa ng karamihan ng trabaho. Sa semicolon at colon pinakamalaki ang pagkakaiba ng mga nagta-type sa C-family at sa Python, kaya magsanay sa mga linya mula sa wikang gamit mo.
• Shell at ang mga kakaiba. Pipe, backslash, tilde, backtick, caret, ampersand, hash, dollar, at-sign at ang key na _. Ang _ at ang backtick ang ikinagugulat ng karamihan; palaging gumagamit ng _ ang code na naka-snake_case, at maling daliri ang ipinampipindot dito ng karamihan.

Isa hanggang dalawang linggo ng sampung-minutong sesyon ang inaabot ng bawat klase para sa karamihan, kaya dalawa hanggang tatlong buwan ang buong track. Mas mabagal iyan kaysa sa pag-aaral ng mga titik, dahil mas malayo ang mga key ng simbolo at mas luma ang mga ugaling pinapalitan mo.

Ang nagkakamali, ayon sa pagmamasid sa stats bawat key: natututunan ng mga tao ang simbolo gamit ang tamang daliri at pagkatapos ay bumabalik sa dati kapag nape-pressure, dahil mas mabilis ang lumang galaw sa loob ng ilang linggo. Lumalabas ito sa stats bilang key na sobrang pabago-bago ang interval, mabilis kapag tama ang abot mo at mabagal kapag hindi. Ang solusyon ay manatili sa klaseng iyon nang isa pang linggo.

Mga pares ng bracket at auto-closing

Awtomatikong isinasara ng mga editor ang mga bracket, kaya makatuwiran ang tanong: bakit pa matututong i-type ang pansara?

Dalawang dahilan. Hindi konsistent ang auto-closing: gumagana ito sa ilang lugar at hindi sa iba, gaya ng terminal o chat window. Nag-aatubili sa bawat pagkakataon ang nagta-type na umaasa rito para tingnan kung gumana ito, at mas malaki ang nawawala sa pag-aatubiling iyon kaysa sa keystroke. At ang pag-type sa ibabaw ng auto-closed na bracket (pagpindot ng ")" kapag naglagay na ng isa ang editor) ay keystroke din, kaya tina-type mo pa rin ang pansarang bracket alinman ang mangyari.

Kapag nagdikit ka ng code sa custom mode dito, hinahati ang teksto sa whitespace, kaya nawawala ang indentation at nagiging salita ang bawat token. Limitasyon at kaginhawahan ito nang sabay: hindi mo tina-type ang apat na space sa simula ng bawat linya ng Python, at hindi mo rin ito nasasanay. Nasa listahan namin ang tunay na code mode na humahawak sa indentation at mga auto-closed na pares gaya ng ginagawa ng editor, at mas mahirap ito kaysa sa tunog nito.

Bilis sa code kumpara sa prosa

Wala pa kaming sapat na resulta sa code mode para maglathala ng mga percentile, at mas gugustuhin naming maghintay kaysa mag-imbento. Sa sarili naming mga takbo, ang bilis sa code sa isang makatotohanang snippet ay nasa kalahati hanggang dalawang-katlo ng bilis sa prosa ng parehong tao, at mas gumaganda ang ratio sa pagsasanay sa simbolo kaysa sa pangkalahatang pagsasanay.

Ang numerong talagang naililipat ay ang katumpakan. Ang programmer na nagta-type ng prosa sa 97% na katumpakan at ng code sa 90% ay may problema sa simbolo, at ipinapakita ng heatmap ng key kung aling mga simbolo mismo. Ang programmer na nasa 97% sa pareho ay kailangan lang mag-type ng mas maraming code. Ipinapaliwanag ng aming metodolohiya sa pagmamarka kung paano binibilang ng katumpakan ang mga naitamang mali.

Para sa karaniwang benchmark, ang punctuation test na naka-on ang mga numero ang pinakamalapit sa code sa aming mga regular na mode. Wala itong braces, pero isinasama nito ang Shift key at ang number row, at para sa karamihan ay iyon ang kulang.

Mga pagpili sa keyboard na nakakatulong

Halos tungkol sa switch ang payo sa keyboard na natatanggap ng mga programmer, at halos wala sa punto.

Mas mahalaga ang layout kaysa sa switch. Iniaakyat ng Dvorak ang mga bracket sa number row at inililipat ang karamihan ng bantas. Pinapanatili ng Colemak at Workman ang mga bracket kung nasaan sila sa QWERTY, pero pareho nilang inililipat ang semicolon sa puwesto ng P sa QWERTY, na mararamdaman ng mga programmer sa C-family. Nasa artikulo tungkol sa mga layout ang mahabang bersyon.

Mas mabuti ang symbol layer kaysa sa mas malaking keyboard. Maraming split at compact keyboard ang nagpapahintulot na ilagay ang mga bracket at operator sa ilalim ng mga daliri sa home row sa isang layer na hawak ng key ng hinlalaki. Sa lahat ng pagbabago sa hardware na inilalarawan ng mga programmer, ito ang una naming susubukan, dahil ibig sabihin nito ay hindi ka na titingin pababa para sa simbolo kailanman.

ISO kumpara sa ANSI. Sa mga ISO keyboard (UK at karamihan ng Europe), binabago ng dagdag na key sa tabi ng kaliwang Shift at ng matangkad na Enter key ang puwesto ng backslash at pipe. Kung sa isa ka nagsasanay at sa isa ka nagtatrabaho, sasablay ang hinliliit mo. Kaya dalawang variant ng Colemak-DH ang kasama sa aming emulation.

Halos walang epekto sa bilis ang mga switch. Nagkakaiba ang linear, tactile at clicky na switch sa pakiramdam at tunog, at hindi alam ng keystroke log kung alin ang pinindot mo. Dinadaanan ng aming artikulo tungkol sa mga mechanical keyboard ang mga numero.

Nakakatulong ang tunog sa ilang tao bilang feedback: sinasabi sa iyo ng tunog ng mali na mali ang isang simbolo nang hindi tumitingin pababa. I-on ito habang nag-aaral ng mga simbolo.

Sampung-minutong sesyon ng programmer

Ang gagawin namin araw-araw sa loob ng dalawa o tatlong buwang inaabot ng symbol track:

• Dalawang minuto: isang 30-segundong words test bilang warm-up, katumpakan sa 97%.
• Anim na minuto: ang kasalukuyang klase ng simbolo, sa custom na teksto na idinikit mula sa sarili mong code. Huminto sa unang senyales ng pagbalik sa lumang daliri.
• Dalawang minuto: isang code snippet sa wikang pinakamadalas mong gamitin. Tingnan pagkatapos ang heatmap ng key, hindi ang WPM.

Sa mga araw na wala kang sampung minuto, ikaw na mismo ang mag-type ng pansarang bracket. Ito ang pinakamaliit na ugali sa artikulong ito at kadalasan ang unang nagbubunga.

Mga madalas itanong

Ano ang magandang typing speed para sa mga programmer?

Magagamit na ang anumang mula mga 40 WPM pataas kung nagto-touch type ka ng mga simbolo at numero. Lampas doon, ang pag-iisip, pagbabasa at husay sa editor ang nagiging hadlang, hindi ang bilis ng daliri.

Paano ako matututong mag-touch type ng mga numero?

Sanayin nang hiwalay ang number row hanggang manatili sa 95% ang katumpakan, gamit ang daliring nasa ibaba mismo ng bawat digit sa home row, pagkatapos ay ihalo ang mga numero sa karaniwang teksto.