Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Branek 12. 09. 2017, 13:24:39
-
Zdravim, poprosim o odpovedi koderu na nasledujici otazky (v zatvorce jsou moje odpovedi):
- Jaky font pouzivate pri programovani ? (PragmataPro 14px)
- Za kterym sloupcem zalamujete - 80, 120, nezalamuji ? (120)
- Mate monitor s editorem otoceny na vysku ? (ano)
- Tema - dark / light ? (pres den light, v noci dark)
- Pripadne shell prikazy spoustite z editoru/IDE nebo terminalu ? (terminal)
- Vyuzivate numericky blok klavesnice - ano/ne/nemam ? (ano)
- Tab nebo space a kolik znaku ? (2x space)
- blokovou { davate pod prikaz nebo vedle nej ? (vedle)
-
1) Hack, 9px
2) 100
3) Zatím ne, ale poslední dobou plánuji buď jako nový druhý monitor s pivotem, nebo nákup většího 4k a nechat na šířku.
4) Light, ale ne bílá. V noci + redshift
5) Depends. Něco je efektivnější z IDE, na něco je lepší srolovat yakuake.
6) Prakticky ne (brzdí to)
7) 4x space programování, 2x space markup (v bývalé práci byly v guidelines 3 mezery, brr…)
8) vedle
-
1) Fira Code 13
2) nezalamuji
3) ne
4) dark
5) z terminalu v IDE
6) ano
7) Tab (velikost 2)
8) vedle
-
1 nevím, font takový, abych na něj viděl
2 nevím, délka řádku taková, aby byl v daném okně vidět celý (výjimečně malinko přesáhnu)
3 monitor na šířku
4 téma nepoužívám
5 shell z terminálu
6 numerické klávesy ano
7 tab 1x
8 blokovou závorku vedle
-
Drápem, vole!
-
1. Consolas 10. Dnes skusam Dejavu Sans Mono
2. mam automaticke zalamovanie (resharper), niekedy ma to serie
3. na sirku, kupil som si 27" (2560x1440p)
4. Light + flux, po veceroch moc nekodim a ak ano, tak mam zasvietene svetlo
5. ako kedy
6. ano
7. tab 4x
8. pod
-
Zdravim, poprosim o odpovedi koderu na nasledujici otazky (v zatvorce jsou moje odpovedi):
- Jaky font pouzivate pri programovani ? (PragmataPro 14px)
Skoč si na voční.
- Tab nebo space a kolik znaku ? (2x space)
Prase!!!
-
Jako že když ty mezery děláš čtyři, tak jsi o půlku lepší programátor? To abych jich tam začal dávat osm...
-
@Branek: Chyba ti tam este "comma-first" style http://ajaxian.com/archives/is-there-something-to-the-crazy-comma-first-style :D
-
Hah, to už jsem taky párkrát viděl a je to fakt humus. A když už jsme u JS, tak někteří si ASI(automatic semicolon insertion) vysvětlili ne jako fallback, ale jako feature a prostě někde nepíšou středníky... Třeba autor bootstrapu se o tom byl schopný pohádat tuším přímo s Brendanem Eichem a to už je opravdu na přesdržku.
-
myslite ze je lepsie mat mensie pismenka a tak nutit oko viac zaostrovat, alebo vacsie? pri 2560x1440p rozliseni a nastaveni velkosti fontu 9 je to prtave. skusil som velkost 10 a v editore zvacsit zoom na 105%.
-
Font se mi líbí "terminus", bývá v Linuxu už v repozitářích např. v Archu nebo v Ubuntu.
-
myslite ze je lepsie mat mensie pismenka a tak nutit oko viac zaostrovat, alebo vacsie? pri 2560x1440p rozliseni a nastaveni velkosti fontu 9 je to prtave. skusil som velkost 10 a v editore zvacsit zoom na 105%.
Ideální je nastavit si to tak, aby tě nebolely oči a bylo to pohodlné. Konkrétní nastavení je opravdu jen a jen na tobě :)
-
Jaky font pouzivate pri programovani (Consolas, 12px)
Za kterym sloupcem zalamujete - zalamuji podle potřeby
Mate monitor s editorem otoceny na vysku ? (nemam) ale asi by se to hodilo
Tema - dark / light ? (stale dark)
Pripadne shell prikazy spoustite z editoru/IDE nebo terminalu ? (terminal)
Vyuzivate numericky blok klavesnice - ? (ano)
Tab nebo space a kolik znaku ? (space)
blokovou { davate pod prikaz nebo vedle nej ? (vedle)
-
1. Terminus 16px (na 28" 4K displeji)
2. Ano, 120
3. Ne
4. Monokai Dark
5. Terminál
6. Ano
7. Tab, který se konvertuje na mezery, podle konvence jazyka
8. Nepíšu v jazyce, který označuje bloky {}
-
Dulezitejsi je spise "Jaky pisete kod"
-
Font - Consolas, Lucida Console, Terminus, cca 10-11px
Zalamujete - když chcu a jak chcu, delší řádky než 120 znaků jsou zřídka třeba
Monitor: na šířku
Tema: dark
Shell: terminal
Numpad: ano
Tab nebo space a kolik znaku ? (tab nastavený na šířku 4 znaků ve všech editorech)
{: vedle, funkce a třídy pod
comma-first: ano 8)
-
Je dávno známo, že lidé používající TAB mají vyšší plat, takže já osobně doporučuji používat TAB místo mezer všude. Od té doby, co jsem to takto začal dělat jsem dostal přidáno. Mám už víc než javaman a to nedělám ani v javě. 8)
-
Je dávno známo, že lidé používající TAB mají vyšší plat, takže já osobně doporučuji používat TAB místo mezer všude. Od té doby, co jsem to takto začal dělat jsem dostal přidáno. Mám už víc než javaman a to nedělám ani v javě. 8)
Hele a nezmylil jsi se kousek ? Protoze vice platej nam spejsistum 8)
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
-
to je nejaka blba statistika. v tom nevidim vobec ziaden zmysel :)
-
1. Dina, 8pt
2. 100
3. ne
4. dark
5. terminal
6. ne
7. space 4x
8. pod
-
To jsou všechno ryze individuální záležitosti (když pominu věci definované nějakou štábní kulturou pro daný projekt), řekl bych.
Mne by spíš zajímalo, zda někdo v editoru používá proporcionální písmo?
(JEN se ptám)
-
1. font FiraMono 13px
2. svislou caru mam na 120 a tam se to snazim i lamat
3. monitor na vysku 8)
4. tema light
5. shelloviny v terminalu
6. numblock hojne vyuzivam, napr /*-+ snad jinak ani nepisu
7. mackam tab ale editor to prevede na 2x space
8. { vedle
9. comma first je blbost
-
To jsou všechno ryze individuální záležitosti (když pominu věci definované nějakou štábní kulturou pro daný projekt), řekl bych.
Mne by spíš zajímalo, zda někdo v editoru používá proporcionální písmo?
(JEN se ptám)
To jsou, ale třeba konkrétně informace o tom, jaký kdo používá font, se může hodit, jako inspirace.
Já o použití proporciálního písma v editoru někde četl, ale když jsem to jen tak letmo zkusil, ale nesedělo mi to. Asi by to chtělo vyzkoušet vícero fontů, ale na to nemám čas.
-
Pouziti proporcionalniho pisma by vyzadovalo dodatecnou inteligenci na strane editoru. Automaticky jsou mimo hry terminalove editory. Dnes vsechny koderske editory tak nejak pocitaji s tim, ze pouzijete monospace font. Hlavne tabovani a zarovnavani by muselo byt reseno inteligentne. Spousta lidi zase zkrasluje kod dodatecnymi mezerami pri logicky souvisejicich blocich, napr. neco takoveho:
stark.name = "Jon";
stark.surname = "Snow";
Proste spousta dilcich problemu s nejasnym vysledkem jestli by mel takovy inteligentni editor vubec prinos. Ale kdyz jsi vezmeme, ze se dnes uz nekterych jazycich daji pouzivat jako nazvy promennych, trid, properties, metod i unicode znaky (hlavne emoji 8) ), ktere casto nepasuji do monospace tak to neni nerealne...
-
- Bitstream Vera Sans Mono 13px
- za zadnym (ve vim :set breakindent)
- monitor na sirku
- jedine dark
- vetsinou terminal
- ne
- tab (zobrazeny jako 3x space)
- vedle
-
Jaky font pouzivate pri programovani (Source Code Pro, 12px)
Za kterym sloupcem zalamujete - zalamuji podle potřeby
Mate monitor s editorem otoceny na vysku ? (nemam) chtělo by to větší velikost a rozlišení
Tema - dark / light ? (stale dark)
Pripadne shell prikazy spoustite z editoru/IDE nebo terminalu ? (yakuake)
Vyuzivate numericky blok klavesnice - ? (ano)
Tab nebo space a kolik znaku ? (tab)
blokovou { davate pod prikaz nebo vedle nej ? (pod)
-
- Fira Code 20px (28'' 4k)
- 120, ale neni problem par znaku pretahnout
- ne - na sirku (ale editor mam na vysku, pulka 4k staci)
- dark (dracula z intellij)
- obcas z IDE, vice z terminalu (pouzivam yakuake)
- num blok mam, ale skoro nepouzivam
- preferuji 2 mezery (v IDE pisu tab, ktery se prevede na mezery), ale zalezi na projektu/jazyku
- { vedle
- ; v JS preferuji, ale mam radsi jazyky bez nich (Scala, Haskell, LiveScript)
Proporcionalni pismo pri programovani, fuj. To jsem videl na nejake prednasce a chvili mi trvalo prijit na to, co tam ma prednasejici spatne. Si pamatuju, jak jsem byl nestastny, kdyz se mi monospace pismo v IDE sazelo tak, ze byly ruzne sirky znaku a rozjizdely se dokumentacni komentare zarovnane pod sebou (bold znaky byly sirsi nez normalni znaky). Nikdy vic.
Mozna by bylo dobre to rozdelit na dve casti - co se po vas chce v praci vs. co preferujete (ne kazdy si muze protlacit svuj styl).
-
Uz dlouho se snazim prijit na duvod, jaka je vyhoda pouzivani mezer misto tabulatoru pro odsazovani radku (nemyslim treba zarovanani "=", a tak, tam to chapu). Jaky k tomu mate duvod (krome toho ze delate na projektu kde se to tak proste dela historicky)?
-
Uz dlouho se snazim prijit na duvod, jaka je vyhoda pouzivani mezer misto tabulatoru pro odsazovani radku
Nasrat normální lidi.
-
Uz dlouho se snazim prijit na duvod, jaka je vyhoda pouzivani mezer misto tabulatoru pro odsazovani radku (nemyslim treba zarovanani "=", a tak, tam to chapu). Jaky k tomu mate duvod (krome toho ze delate na projektu kde se to tak proste dela historicky)?
No protoze v tom byl gulas. Kdyz uz nahodou vetsina lidi respektovala tabulatory, tak obcas tam misto toho byla mezera a pak se cele formatovani rozjelo. U mezer musi byt clovek hodne velky ignorant, aby si nevsiml, ze nedodrzuje mezery.
Chapu vyhody tabulatoru, ale bohuzel.
BTW historicky se pouzival tabulator pozdeji jsme to cele predelali na mezery.
p.s. schvalne kolik lidi v makefile pouzilo aspon jednou mezery misto tabulatoru a pak na to dlouho nemohli prijit :).
-
1. Source Code Pro 12px
2. 120
3. kedysi FHD na vysku, teraz 2560x1440 na sirku + v druhom na vysku mam browser
4. dark (darcula intelliJ)
5. git, build, run, deploy ako commandy v IntelliJ, ale ssh-ckujem zo samostatneho terminalu ked je treba
6. pri pisani kodu nepouzivam.., v kalkulacke hej
7. 4x space Python (PEP-8), makefile Tab, zvysok 2x space
8. vedla, setrime vertikalnym miestom predsa
Uz dlouho se snazim prijit na duvod, jaka je vyhoda pouzivani mezer misto tabulatoru pro odsazovani radku (nemyslim treba zarovanani "=", a tak, tam to chapu). Jaky k tomu mate duvod (krome toho ze delate na projektu kde se to tak proste dela historicky)?
s medzerami sa kod zobrazi vsade rovnako, tabulator moze mat kazdy nastaveny inac.., su ludia, co maju editor nastaveny tak, ze im tabulator zobrazi ako 2 medzery.., potom napisu kod, v ktorom tabulatormi odsadia o 5 urovni, spravia PR na githube, a neda sa to tam citat, lebo github zobrazuje tabulator ako 8 medzier :D
-
su ludia, co maju editor nastaveny tak, ze im tabulator zobrazi ako 2 medzery..,
Sakra, to je ale svinstvo, nastavovat si editor tak, jak to lidem vyhovuje.
spravia PR na githube, a neda sa to tam citat, lebo github zobrazuje tabulator ako 8 medzier :D
GH zobrazuje tabulátor tak, jak si to v repozitáři nastavíš přes .editorconfig.
-
.editorconfig
[*]
indent_style = space
indent_size = 2
A muzete mackat tabulator a ono to uz udela spejsy za vas. Fakt to bude vsude stejny na rozdil od \t.
-
Uz dlouho se snazim prijit na duvod, jaka je vyhoda pouzivani mezer misto tabulatoru pro odsazovani radku (nemyslim treba zarovanani "=", a tak, tam to chapu). Jaky k tomu mate duvod (krome toho ze delate na projektu kde se to tak proste dela historicky)?
Protože se to pak vždycky jednou za čas někde smíchá pěkně dohromady a je v tom v lepším případě bordel, v horším to přestane fungovat. U mezer problém vidíš okamžitě. Kdysi dávno jsem taky používal taby, teď radši mezery, pokud se to někde výslovně nevyžaduje jinak. Lidi, které "nasere" taková drobnost netřeba brát v úvahu, ty zřejmě rozhodí cokoliv, kde musí trochu přizpůsobit styl práce.
-
Uz dlouho se snazim prijit na duvod, jaka je vyhoda pouzivani mezer misto tabulatoru pro odsazovani radku (nemyslim treba zarovanani "=", a tak, tam to chapu). Jaky k tomu mate duvod (krome toho ze delate na projektu kde se to tak proste dela historicky)?
Například protože to je konvence daného jazyka. Například Ruby a Elixir mají konvenci 2 mezery a drtivá většina vývojářů to dodržuje. A ani to moc neotravuje, když se snad každý editor dá nastavit, aby TABy převáděl na mezery podle toho, jak si to nastavím pro daný jazyk.
-
A muzete mackat tabulator a ono to uz udela spejsy za vas. Fakt to bude vsude stejny na rozdil od \t.
Nic ve zlym, ale ja jsem se fakt neptal jak ohackovat editor aby predelaval taby na mezery...
Ale ok, potvrzuje se mi ze logiku to nema, jen nekterym lidem vadi ze by si ostatni mohli nastavit sirku tabelatoru podle sebe a radsi jim budou nutit jejich nesmyslny predstavy o tom jak by mel byt radek odsazeny. ("to bude vsude stejny", "s medzerami sa kod zobrazi vsade rovnako", ... wtf?? co je vam do toho jak se to me zobrazi? zaklad je nepsat jak prase...)
-
nutit jejich nesmyslny predstavy o tom jak by mel byt radek odsazeny. ("to bude vsude stejny", "s medzerami sa kod zobrazi vsade rovnako", ... wtf?? co je vam do toho jak se to me zobrazi? zaklad je nepsat jak prase...)
O co, ze uhodnu kolik ti je?
-
1. ten co je nastaveny v IDEA by default neviem co to je
2. nezalamujem ale mam to nastavene na 128
3. nie
4. light a v noci flux
5. terminal ale ako kedy
6. nie
7. tab nastaveny na 4 medzery
8. vedla
-
co je vam do toho jak se to me zobrazi?
Do toho mi je setsakra moc! Jak to chces videt ty je tvuj problem. Ja resim mezerama to, ze v teamovem kodeni je deset lidi a deset chuti a deset IDE a deset nastaveni. Kdyz dam natvrdo mezery tak to vsude bude stejny a ocekavam, ze po zmenach od kolegu to tak i zustane. Editorconfig to nikdy neporesi uplne protoze jsou editory co to neznaj nebo forcnou po svem tak jako tak. Takze mame krute nastaveny lintery a jestli nejakej uchyl pouzije 0x09 misto 0x20 tak mu to vypinda a nepushne si >:(
-
co je vam do toho jak se to me zobrazi?
Do toho mi je setsakra moc! Jak to chces videt ty je tvuj problem. Ja resim mezerama to, ze v teamovem kodeni je deset lidi a deset chuti a deset IDE a deset nastaveni. Kdyz dam natvrdo mezery tak to vsude bude stejny a ocekavam, ze po zmenach od kolegu to tak i zustane. Editorconfig to nikdy neporesi uplne protoze jsou editory co to neznaj nebo forcnou po svem tak jako tak. Takze mame krute nastaveny lintery a jestli nejakej uchyl pouzije 0x09 misto 0x20 tak mu to vypinda a nepushne si >:(
Aha, takže ve skutečnosti by stačilo nastavit ten tvůj krutě nastavený linter přesně obráceně a bylo by to stejně tak všude stejný, ale zato bys nevnucoval ostatním své představy, jak to má vypadat na jejich obrazovce a nemoh bys pohonit v diskusi nad tím, jakej jseš kápo. No, to by bylo hrozný. ::) ;D
-
1. DejaVu Sans Mono
2. aby sa kód vošiel do okna
3. nie
4. light
5. terminal
6. ano
7. podľa projektu, pri vlastných 2x space
8. ako kedy, zvyčajne vedľa, ak je dlhší if/for tak pod (kvôli čitateľnosti)
-
Aha, takže ve skutečnosti by stačilo nastavit ten tvůj krutě nastavený linter přesně obráceně..
Ja vim kam miris, teoreticky ano. Sam jsem byl kdysi tabista, ale v praxi se to holt neosvedcilo. Tak se udelala anketa mezi seniory a vznikl 2space konsenzus (po vasnivych hadkach a naslednem usmireni na pivu) a tak se to nastavilo v best practices, linterech a pravidlech pro review. Od te doby (a ze je to uz snad petiletka) je klid a mir :-*
-
co je vam do toho jak se to me zobrazi?
Do toho mi je setsakra moc! Jak to chces videt ty je tvuj problem. Ja resim mezerama to, ze v teamovem kodeni je deset lidi a deset chuti a deset IDE a deset nastaveni. Kdyz dam natvrdo mezery tak to vsude bude stejny a ocekavam, ze po zmenach od kolegu to tak i zustane. Editorconfig to nikdy neporesi uplne protoze jsou editory co to neznaj nebo forcnou po svem tak jako tak. Takze mame krute nastaveny lintery a jestli nejakej uchyl pouzije 0x09 misto 0x20 tak mu to vypinda a nepushne si >:(
kontrolu stylu by neměl provádět editor, ale externí tool, který si nastaví všichni stejně. Taby za mezery umí nahrazovat všechny editory.
-
- Default IntelliJ, default Notepad, default VIM, default Sublime. Proste je mi to celkem jedno.
- Aby se to veslo a zalomeni zaroven bylo v nejakem logickem bode.
- nemam, tuhle hipsterinu nechapu, radsi jsem si domu koupil vetsi monitor a v praci vyzebral taky velkej
- Vzdy na strane dobra. Ale ja si vzdy rad prisvitim. Nechapu lidi co cumej do svitciho monitoru v absolutni tme.
- terminal.
- Kdyz musim dlouhou radu cisel. Coz delam nerad a vyhybam se tomu.
- Stisknuti Tab mi hodi 4xspace
- blokovou { vedle
-
- Vzdy na strane dobra. Ale ja si vzdy rad prisvitim. Nechapu lidi co cumej do svitciho monitoru v absolutni tme.
Mozna jsem vyjimka, ale mam dark theme vsude (kde to jde) a pri praci mam roznuto.
-
- Jaky font pouzivate pri programovani? (DejaVu Sans Mono 14px)
- Za kterym sloupcem zalamujete? (80 - zpravidla nezalamuji)
- Mate monitor s editorem otoceny na vysku? (ne)
- Tema - dark/light? (light + redshift)
- Pripadne shell prikazy spoustite z editoru/IDE nebo terminalu? (editor i terminál dle potřeby)
- Vyuzivate numericky blok klavesnice? (ano)
- Tab nebo space a kolik znaku? (autoindent, resp. tab, který je konvertován dle typu souboru a projektu)
- blokovou { davate pod prikaz nebo vedle nej ? (vedle)
- Píšete mezeru před otazníkem? (ne)
- Max. úroveň odsazení? (4)
-
kontrolu stylu by neměl provádět editor, ale externí tool, který si nastaví všichni stejně. Taby za mezery umí nahrazovat všechny editory.
Nejlépe takový filtr narvat do Gitu na serveru a je pokoj. Každý si pak může psát jak chce.
BTW: Docela mi vadí chybějící LF na koncích zdrojáků. Editor mi je tam automaticky doplňuje, ale v diffu to pak vypadá divně.
-
... BTW: Docela mi vadí chybějící LF na koncích zdrojáků. Editor mi je tam automaticky doplňuje, ale v diffu to pak vypadá divně.
Neumnel tohle git nejak sam resit?
-
... BTW: Docela mi vadí chybějící LF na koncích zdrojáků. Editor mi je tam automaticky doplňuje, ale v diffu to pak vypadá divně.
Neumnel tohle git nejak sam resit?
Jasne, ze umi. Defaultne je v repozitari LF a ve windows gitu je zas nastaveno, ze pull prida CR a push zase odebere CR. Navic vetsina diffu napr. v Stash, BitBucket, GitHub ma prepinac "ignore whitespaces".
-
... BTW: Docela mi vadí chybějící LF na koncích zdrojáků. Editor mi je tam automaticky doplňuje, ale v diffu to pak vypadá divně.
Neumnel tohle git nejak sam resit?
Jasne, ze umi. Defaultne je v repozitari LF a ve windows gitu je zas nastaveno, ze pull prida CR a push zase odebere CR. Navic vetsina diffu napr. v Stash, BitBucket, GitHub ma prepinac "ignore whitespaces".
Nejedná se o chybějící LF na konci řádku, ale na konci souboru. Kdyby je tam Git dopisoval, bylo by to fajn.
-
Jaky font pouzivate pri programovani? (DejaVu Sans Mono 14px)
zle vidis?
nedavno som zacal pouzivat to iste pismo na velkosti 10. Predtym som mal Consolas tiez na 10 a Dejavu je vacsie. Pri 14 su to velke kravy
-
Jaky font pouzivate pri programovani? (DejaVu Sans Mono 14px)
zle vidis?
nedavno som zacal pouzivat to iste pismo na velkosti 10. Predtym som mal Consolas tiez na 10 a Dejavu je vacsie. Pri 14 su to velke kravy
40 řádek zdrojáku na stránce mi bohatě stačí. Aspoň na to nemusím mžourat.
-
Neni font jako font, nekde je ok 10px nekde az 14px, obzvlast pri 4K a zoomovackach. Napr. na mem FullHD 24" mi jeden font pri 14px da na fullscreen editoru 240 sloupcu x 42 radku. Jiny pri 11px 240x48. Proste sirka pismenek je zhruba stejna ale vyska a lineheight dost jina.
Takze tu velikost moc nereste, zavisi jak od hardware tak od fontu.
-
... Takze tu velikost moc nereste, zavisi jak od hardware tak od fontu.
+1
Je to presne tak. Ja s 20 fontem vidim 70radek a staci mi to (v distraction free modu 80, ale to bezne nepouzivam).
-
1..5 - Midnight Commander
6 - na čísla, protože česká klávesnice
7..8 - Whitesmiths podle délky prvního slova na řádku.
-
- Hack 11px
- nezalamuji
- ne
- dark a redshift
- terminal
- ano
- tab, pocet mezer podle toho co pisu
- vedle
-
Asi budu divnej, ale střídám tři stroje (v práci, noťas a doma), dva OS, celkem tři velikosti monitorů, + ladění embedded potvor... Takže asi takhle:
1. Cokoliv, co je monospace a dá se na daným HW rozumně použít. Btw, jak se mění font ve VIMu?
2. Já mám tak trochu úchylný systém. Čáru mám na stovce, vlevo od ní mám kód, vpravo 20 znaků na "bookmarky" s hintem. Líp se mě v tom orientuje, když hledám něco podstatnýho.
3. Ne, na noťasu by to ostatně šlo dost blbě. Po stranách mám navigační panel, watche, stack, registry, historii..., takže ani na 24" krávě není důvod otáčet. Místo na výšku viz 8
4. Furt to samý. V IDE light, ve terminálu dark. Den/noc hlídá redshift, nebudu se s tím přece přepínat ručně a skokově.
5. Terminál. Nemám rád, když si konzolu IDE samo otevírá, zavírá, maže a něco si připisuje. Btw, GIT taky jedině v terminálu, je to rychlejší než omalovánky v IDE
6. Na řady čísel dobrý, ale proč se neptáš na potkyša?
7. 2x space bez diskuse - je to přehledný a nežere to zbytečný místo na šířku. Sázím je tam tabelátorem, nebo IDE odsazuje automaticky. Jde při tom o zarovnání tabulek a komentářů (někdy je tam potřeba lichý počet mezer, výhradně s TABem to nejde + kompatibilita s ostatníma)
8. Jasně že na konec řádku. Odsazený blok přece vidím a nemá cenu si natahovat zdrojáky. Pokud to teda nevyžaduje zaměstnavatel jinak (třeba kdyby mě chtěl platit od LOC, tak klidně hodím na samostatný řádek každý argument funkce v deklaraci :D ).
-
Pro Vim v terminálu prostě změníš font celého terminálu. A v gvim je na to příkaz.
-
Pro Vim v terminálu prostě změníš font celého terminálu. A v gvim je na to příkaz.
V Gvim si můžeš zvolit pro každý typ slova jiný font, ale vypadá to pak dost šíleně. Ovšem v Gvimu chybí spousta užitečných vlastností a vůbec mi nesedl, používám tedy konzolový Vim.
-
Ti VIckari jsou jak vegani ci jehoviste, hned vam to zavesi na nos ;D
-
Ti VIckari jsou jak vegani ci jehoviste, hned vam to zavesi na nos ;D
Co bys chtěl používat místo Vimu, když pro konzoli nic rozumnějšího nenajdeš?
-
Ti VIckari jsou jak vegani ci jehoviste, hned vam to zavesi na nos ;D
Co bys chtěl používat místo Vimu, když pro konzoli nic rozumnějšího nenajdeš?
Vsiml jsi si ze je rok 2017 ? Mi rekni KDO uz programuje DNES v terminalu a jeste k tomu ve VI* ? Jeden z tisice a i ten ma poruchu osobnosti... Timhle pokladam tema Vi za vycerpane a ukoncene, howgh.
-
Ti VIckari jsou jak vegani ci jehoviste, hned vam to zavesi na nos ;D
Co bys chtěl používat místo Vimu, když pro konzoli nic rozumnějšího nenajdeš?
Vsiml jsi si ze je rok 2017 ? Mi rekni KDO uz programuje DNES v terminalu a jeste k tomu ve VI* ? Jeden z tisice a i ten ma poruchu osobnosti... Timhle pokladam tema Vi za vycerpane a ukoncene, howgh.
Ja programujem vo Visual Studiu a na vsetko pouzivam mys jedine 2 klavesove skratky ktore poznam su ctrl+c a ctrl+v
Teda poznam aj F5 ale radsej klikam misou na zelenu sipku.
No tiez mam poruchu osobnosti som vybusny cholerik a asi aj narcista a hysterik.
-
Ti VIckari jsou jak vegani ci jehoviste, hned vam to zavesi na nos ;D
Co bys chtěl používat místo Vimu, když pro konzoli nic rozumnějšího nenajdeš?
Vsiml jsi si ze je rok 2017 ? Mi rekni KDO uz programuje DNES v terminalu a jeste k tomu ve VI* ? Jeden z tisice a i ten ma poruchu osobnosti... Timhle pokladam tema Vi za vycerpane a ukoncene, howgh.
Chceš mi snad tvrdit, že těch 10 % uživatelů, kteří používají Vim, trpí poruchou osobnosti?
Když se připojíš na server přes SSH, tak máš k dispozici snad něco jiného než konzoli?
Tímto považuji diskuzi o Vimu za uzavřenou.
-
Ja programujem vo Visual Studiu a na vsetko pouzivam mys jedine 2 klavesove skratky ktore poznam su ctrl+c a ctrl+v
Teda poznam aj F5 ale radsej klikam misou na zelenu sipku.
No tiez mam poruchu osobnosti som vybusny cholerik a asi aj narcista a hysterik.
Také musíš vymýšlet a psát názvy tříd, objektů a metod. To se naklikat dost dobře nedá a IDE to za tebe neudělá (a pokud udělá, tak se to nedá číst).
Nevím, co ve VS dělá F5, mně to otvírá konfiguraci editoru. F9 používám na spouštění jednotkových testů pro třídu, kterou zrovna píši. Pokud potřebuji třeba seřadit některé řádky podle abecedy, označím je a zavolám si externí sort.
-
Co bys chtěl používat místo Vimu, když pro konzoli nic rozumnějšího nenajdeš?
Nepouzivat konzolu?
Teda neviem kto normalny programuje v konzole, mozno vy phpckari ste tak trochu uleteni, tazko povedat
-
Co bys chtěl používat místo Vimu, když pro konzoli nic rozumnějšího nenajdeš?
Nepouzivat konzolu?
Teda neviem kto normalny programuje v konzole, mozno vy phpckari ste tak trochu uleteni, tazko povedat
Jak chceš nepoužívat konzolu, když jsi připojen přes SSH k serveru, na kterém není Xclient?
-
Ti VIckari jsou jak vegani ci jehoviste, hned vam to zavesi na nos ;D
Co bys chtěl používat místo Vimu, když pro konzoli nic rozumnějšího nenajdeš?
Vsiml jsi si ze je rok 2017 ? Mi rekni KDO uz programuje DNES v terminalu a jeste k tomu ve VI* ? Jeden z tisice a i ten ma poruchu osobnosti... Timhle pokladam tema Vi za vycerpane a ukoncene, howgh.
"Programuje" asi ne.. Uprava skriptu nebo napsani "udelatka" na par radku je snad beznej chleba, ne ?
-
Vsiml jsi si ze je rok 2017 ? Mi rekni KDO uz programuje DNES v terminalu a jeste k tomu ve VI* ? Jeden z tisice a i ten ma poruchu osobnosti... Timhle pokladam tema Vi za vycerpane a ukoncene, howgh.
Já třeba používám Sublime, ale VIM používám na rychlou editaci malých souborů, nebo když něco potřebuju nastavit na serveru přes SSH. Ale všiml jsem si, že lidé, kteří kdysi používali TextMate, tak buď zdrhli k Atomu, nebo začali používat VIM a nepřišlo mi, že by měli poruchu osobnosti.
-
Co bys chtěl používat místo Vimu, když pro konzoli nic rozumnějšího nenajdeš?
Nepouzivat konzolu?
Teda neviem kto normalny programuje v konzole, mozno vy phpckari ste tak trochu uleteni, tazko povedat
Jak chceš nepoužívat konzolu, když jsi připojen přes SSH k serveru, na kterém není Xclient?
Preto take veci nerobim
-
Jak chceš nepoužívat konzolu, když jsi připojen přes SSH k serveru, na kterém není Xclient?
Preto take veci nerobim
Tak si dělej v čem chceš a nezáviď. Volba textového editoru nebo IDE je na každém z nás. Také nerýpu do lidí, kteří používají IDE v GUI.
-
Jak chceš nepoužívat konzolu, když jsi připojen přes SSH k serveru, na kterém není Xclient?
A to je programovani? Vzdyt si to stahnu z gitu, programuji lokalne, pushnu, deploy. Teda aspon tak to delaj normalni programatori a ne amatersti pristipkari pres ssh.
-
+1.
nekde este ludia zaspali dobu :D
-
Já třeba používám Sublime, ale VIM používám na rychlou editaci malých souborů, nebo když něco potřebuju nastavit na serveru přes SSH. Ale všiml jsem si, že lidé, kteří kdysi používali TextMate, tak buď zdrhli k Atomu, nebo začali používat VIM a nepřišlo mi, že by měli poruchu osobnosti.
Většina zdrojáků je dnes v drobných souborech na několik desítek řádek, ale když jsem se hrabal ve WordPressu, tak to ve Vimu šlo docela svižně, i když ten zdroják měl přes 30k řádek. Pokud je v nějakém adresáři pár desítek tisíc souborů, tak je většina IDE v háji, ale Vimu to nevadí.
Velkým nešvarem uživatelů dnešních IDE jsou pleonasmy v názvech souborů. Vidím to skoro v každém projektu, který je ve více podadresářích. Kdyby používali Vim, tak by je to rovnou praštilo přes nos a takové hlouposti by nedělali.
-
Vsiml jsi si ze je rok 2017 ? Mi rekni KDO uz programuje DNES v terminalu a jeste k tomu ve VI* ? Jeden z tisice a i ten ma poruchu osobnosti... Timhle pokladam tema Vi za vycerpane a ukoncene, howgh.
Všiml jsem si že je rok 2017. Proto používám VIM a ne VI.
Jestli ti to totiž neuniklo, náplní práce sofťáka je i použití vzdálených toolů - unit testy (u embeďáka, co dělá desku na Linuxu bez GUI, se bez konzoly nedá), konfigurace pana Jenkinse (taky přes konzolu někde na serveru), konfigurace repozitáře, povolení si portu na firewallu,... Tam je VI/VIM jistota.
A náhodou, konzola je super vynález. Víš, jak efektivně urychlí práci sofťáka? V minulé práci jsme měli výrobek, kde bylo několik mikrokontrolérů na jedné desce a byl požadavek udělat balík pro instalaci, ve kterým byla nějaká hlavička ohledně produktu, pak binárky rozšířený o jejich hlavičky. No a paralelně k tomu samostatný binýárky, co se pálily do výrobku na lince. Vývoj toho nástroje, co to balil, dostal na starost frikulín jako ty. Dopadlo to nejhůř, jak mohlo. Klikací bestie v C#. A víš proč?
- Než člověk udělal release, musel si ten bazmek dostat do komplu. To znamenalo sehnat nejenom binárku, ale i .NET správné verze.
- Embeďáci neměli plnou verzi toho M$VS, co měl on, a v jiné verzi to po něm nešlo buildovat a když byl problém, musel člověk čekat, než jeho frikulínstvo hne zadekí a fixne to.
- Marketing záhy přišel s několika variantama toho produktu (lišící se například jazykem, logem odběratele při bootu,...) a bylo potřeba je do toho toolu přidat. Myslíš, že to hovado se obtěžovalo s nějakým XMLkem nebo aspoň starým dobrým INI? Ne, všechno natvrdo v kódu. Viz bod 2. Mezi 30 vývojářama byli dva schopní toho, aby upravili "toolu pro všeobecný použití", jak tomu před managerama říkali, konfiguraci hlavičky.
- Před spuštěním bylo potřeba naklikat asi 20 parametrů (ohledně typu MCU, verze jednotlivých SW, vybrat produkt, sdělit cesty,...). Frikulína nenapadlo mít možnost uložit konfiguraci do souboru, takže se všechno naklikávalo ručně.
- Frikulín neznal parsování, přece není debil, aby tam zadal nějakou blbou hodnotu. A výjimky pro něho byly sprostý slovo. Takže když člověk nezadal cestu k souboru, protože se teprve buildovalo, a chtěl zatím vyplnit verzi SW, zbuchlo to, protože soubor neexistoval a hurá od začátku.
- Možnost spustit updatebuilder.exe s parametry nebyla, uráželo to jeho víru GUI widlí
- Následkem toho všeho trvala konfigurace 30 minut, build binárek taky 30 minut. Sama práce prográmku byla na 5s.
Při pěti variantách produktu to bylo pět hodin, kdy u toho musel člověk sedět, protože musel klikat jak debil. Místo toho, aby člověk prostě v GITu přidal změny do větve pro release, Jenkins to v noci zbuildoval a následně spustil něco z command line a rovnou zahlásil, že balíček pro update byl úspěšně sestaven. To je totiž to pravý řešení pro rok 2017 - nech rutinní práci na automatice, jenom zkontroluj výsledek. A ani nemusí vědět, že pracuje s GITem - ony se ty příkazy dají hodit do shell scriptu, takže stačí napsat "release" do konzoly a odentrovat. A za 4h je v mailu zpráva, jak to dopadlo. Jenom poslat soubory ze serveru, kam patří.
A bez toolů jako make, kompilátor, linker, ... uděláš prd i v lokále. I ty softy na střih videa koneckonců často používají ffmpeg apod. A všechno je to ovládaný z toho fujtajbl příkazovýho řádku, jenom to před tebou IDE nebo softy s GUI úspěšně tají.
Jak chceš nepoužívat konzolu, když jsi připojen přes SSH k serveru, na kterém není Xclient?
A to je programovani? Vzdyt si to stahnu z gitu, programuji lokalne, pushnu, deploy. Teda aspon tak to delaj normalni programatori a ne amatersti pristipkari pres ssh.
Jo, ale ten push spustí nějakou akci na serveru, která spouští po sobě jeden CLI program za druhým, dokud nedojde do požadovanýho cíle. Ty to jenom nevidíš, ale bez command line bys byl v pr... Tak se laskavě neposmívej těm, kdo ti to ve VIMu tak krásně připravili, nebo ti jednoho krásnýho dne přes SSH změní jedno písmenko v těch skriptech a máš vymalováno.
-
kolko ludi sa pripaja cez ssh a pouziva VIM cez ktory programuje? robite tu z toho, ako keby je to normalne a robi sa to vo velkom
-
kolko ludi sa pripaja cez ssh a pouziva VIM cez ktory programuje? robite tu z toho, ako keby je to normalne a robi sa to vo velkom
Uznávám, že těch cca 10 % programátorů, kteří používají Vim, není zrovna programováním ve velkém.
-
- Jaky font pouzivate pri programovani? - záleží na platformě, Mac + Linux mám DejaVu Sans Mono / Menlo 12px), ve Windows Consolas 12px
- Za kterym sloupcem zalamujete? - samozřejm 80, ale kód formátuji pomocí Prettier
- Mate monitor s editorem otoceny na vysku? - ne, mám 2x 4k na Linuxu a Win. Na Macku mi stačí Retina
- Tema - dark/light? - dark + nightshit
- Pripadne shell prikazy spoustite z editoru/IDE nebo terminalu? - primárně terminál, ale záleží na IDE v kterém jsem -
JetBrains mají dobrý, Visual Code + Atom je katastrofa, o VS raději nemluvím :D - Vyuzivate numericky blok klavesnice? - ne, k čemu :-D. Od doby co mám Mac, nepotřebuji ani myš
- Tab nebo space a kolik znaku? - mezera, ale jak jsem psal, používám Prettier
- blokovou { davate pod prikaz nebo vedle nej ? - na stejnou řádku a otazník dávám bez mezery... ;-)
Na podobné téma, tj. code standards jsem se účastnil již mnoho debat. Každý člověk má svůj názor a je to nekonečná debata. Od doby, co jsem objevil Prettier mě absolutně nezajímá co a jak píše kód. Po uložení souboru se prostě přeformátuje podle standardu a konec diskuzí. Pak se nestane, že jeden používá mezery a jiný taby, jeden chlupaté závorky na nové řádce atd. Prostě mají všichni stejně formátovaný kód a je klid. Nehledě na to, že žabomyší války o mezeře / tabu jsou k ničemu.
Obecně si myslím, a také to ve firmě zastávám, že je mi jedno, v čem mi programátoři píší (jsou tu lidé s Mackem, s Win, s Linuxem), ale zajímá mě produktivita a je mi úplně jedno, jestli má IDE nebo Vim (á třeba programoval ve Vimu 8 let a byl jsem spokojený).
-
... Velkým nešvarem uživatelů dnešních IDE jsou pleonasmy v názvech souborů. Vidím to skoro v každém projektu, který je ve více podadresářích. Kdyby používali Vim, tak by je to rovnou praštilo přes nos a takové hlouposti by nedělali.
To jako protoze Vim ma problem s navigaci, tak je problem s ostatnimi programatory pouzivajicimi IDE? Co si vzpominam, tak treba v Angularu byla best practise poradne pojmenovavat komponentu, prestoze to jmeno uz bylo v ceste (napr. components/page/about/about-page.component.ts). A teda myslim, ze se to stejne razi i v Jave.
Posledne, co sme tu v nejakem vlakne srovnavali Vim a IDEA praci v Jave, z toho vysel Vim dost slabe - neumnel ani zakladni refaktorovani (prejmenovani tridy/fieldu, ktery v projektu existuje v ruznych kontextech) a myslim mel i problem s opravdovou navigaci.
At si kazdy pouziva co chce. Ale hlasat jak je Vim nejlepsi nastroj na vyvoj a pak neumi ani triviality, ktere umely opravdova IDE roky (desetileti spis) zpet a reagovat tim, ze to neni potreba, protoze prece opravdovy programator to pise tak, ze to nikdy nebude treba refaktorovat a ze se nikdy nezmeni zadani a dalsi podobne bludy... To mozna funguje na malych projektech v jednom cloveku, i tak si myslim, ze to akorat povede k prasecimu kodu, protoze se nepouziva nastroj, ktery refaktorovani pohodlne zvlada, takze to programator rucne delat nebude a nejak si to ospravedlni.
...
Jeden uzivatel IDE prasi, takze vsichni uzivatele IDE prasi? Nebo co se tim snazite rict? Ja pouzivam IDE a napr. z IDE pracuji s Gitem, protoze to je rychlejsi, nez z konzole (vidim diff s formatovanim, mohu z jakehokoliv mista diffu skocit do zdrojaku v IDE a pripadne upravit, snad na vsechny akce existuje klavesova zkratka [pripadne lze nastavit], takze rozdil v rychlosti tam nebude; mozna bude naopak cista konzole pomalejsi). Co ma smysl, to pouzivam z konzole (v mem pripade treba spousteni testu, sprava baliku), rozhodne tedy neplati "uzivatel IDE == nepouziva na nic konzoli". Stejne tak neplati, ze "uzivatel IDE == pouziva Windows" (muj hlavni OS je Tux).
-
... Velkým nešvarem uživatelů dnešních IDE jsou pleonasmy v názvech souborů. Vidím to skoro v každém projektu, který je ve více podadresářích. Kdyby používali Vim, tak by je to rovnou praštilo přes nos a takové hlouposti by nedělali.
To jako protoze Vim ma problem s navigaci, tak je problem s ostatnimi programatory pouzivajicimi IDE? Co si vzpominam, tak treba v Angularu byla best practise poradne pojmenovavat komponentu, prestoze to jmeno uz bylo v ceste (napr. components/page/about/about-page.component.ts). A teda myslim, ze se to stejne razi i v Jave.
Ten princip tahání cesty k suboru d ozdrojáku je na blití. Vždycky. Kód je kód. Soubor s kódem je soubor s kódem. Cesta k souboru je cesta k souboru. Při překladu nesmí záležet na tom, jak a kam to bylo uloženo.
S tím mícháním mě vždycky tak nechutně vytáčel už Pascal - ukazatel POpenDialog, třída TOpenDialog, instance OpenDialog a jak nazvat soubor, když to není case sensitive a opendialog.pas hodí chybu duplicitního identifikátoru? Jak u blbečků na dvorečku. Jenom proto, aby to měl kompilátor jednodušší :(
Úplně jiná kategorie jsou pak kreténi, kteří udělají nějaký IDE a když člověk přidává soubor, musí přes absolutní cestu (C::B například). Takže já si udělám v /home/petr/projekty/abc/xzy.c, commitnu to včetně projektovýho souboru a Lojza, protože to má v /home/lojza/projekty/abc/, to neotevře a řeší konflikt v projektovým souboru... Resp. ho řeší při každým pull requestu, nabo musí být projektový soubor v .gitignore, nebo hledat další řešení... Tam by si zasloužil autor toho nesmtyslu takovou po papuli, že se bude týden na židli točit. A jak se dotočí, tak druhou, stejně silnou na druhou stranu, aby si uvědomil, že to trochu přepískl.
...
Jeden uzivatel IDE prasi, takze vsichni uzivatele IDE prasi? Nebo co se tim snazite rict? Ja pouzivam IDE a napr. z IDE pracuji s Gitem, protoze to je rychlejsi, nez z konzole (vidim diff s formatovanim, mohu z jakehokoliv mista diffu skocit do zdrojaku v IDE a pripadne upravit, snad na vsechny akce existuje klavesova zkratka [pripadne lze nastavit], takze rozdil v rychlosti tam nebude; mozna bude naopak cista konzole pomalejsi). Co ma smysl, to pouzivam z konzole (v mem pripade treba spousteni testu, sprava baliku), rozhodne tedy neplati "uzivatel IDE == nepouziva na nic konzoli". Stejne tak neplati, ze "uzivatel IDE == pouziva Windows" (muj hlavni OS je Tux).
Chci tím říct, že
a) bez command line se neobejdeme, ani kdyby se frikulíni s jejich klikátkma na přirození stavěli
b) program, co nemá možnost ovládání přes CLI, jako tool pro vývoj neobstojí ani náhodou
c) že moje osobní zkušenost je taková, že kdo nemá mentální kapacitu na zapamatování pár klávesových zkratek a pár příkazů na konzole, ten nemá na 99% mentální kapacitu ani na to, aby napsal program dobře (chybí výjimky, validace, ...). Což ale samozřejmě neznamená, že zdatný uživatel command line napíše dobrý programy.
d) nikdy nenechávej narcistu programovat něco, co budou používat ostatní.
-
... Velkým nešvarem uživatelů dnešních IDE jsou pleonasmy v názvech souborů. Vidím to skoro v každém projektu, který je ve více podadresářích. Kdyby používali Vim, tak by je to rovnou praštilo přes nos a takové hlouposti by nedělali.
To jako protoze Vim ma problem s navigaci, tak je problem s ostatnimi programatory pouzivajicimi IDE? Co si vzpominam, tak treba v Angularu byla best practise poradne pojmenovavat komponentu, prestoze to jmeno uz bylo v ceste (napr. components/page/about/about-page.component.ts). A teda myslim, ze se to stejne razi i v Jave.
Vim nemá problém s navigací, ale IDE tyhle problémy mají a proto používají zkriplené názvy souborů i tříd.
Podstatné je, že se ty zkriplené názvy blbě čtou. Namespace je namespace a v názvu třídy nemá co pohledávat. Pokud ti chybí, používej fullpath - ušetříš tím řádek v importech. Hezky to má vyřešeno například Haskell, ale ani PHP není pozadu.
Posledne, co sme tu v nejakem vlakne srovnavali Vim a IDEA praci v Jave, z toho vysel Vim dost slabe - neumnel ani zakladni refaktorovani (prejmenovani tridy/fieldu, ktery v projektu existuje v ruznych kontextech) a myslim mel i problem s opravdovou navigaci.
Hlavně jsme se neshodli v tom, že uvedený příklad není refaktorování, ale redesign. Rozhraní tříd by mělo být svaté. Dle OCP ho můžeš rozšířit, ale nesmíš ho měnit. Jinak zaděláváš na problémy ostatním kolegům.
At si kazdy pouziva co chce. Ale hlasat jak je Vim nejlepsi nastroj na vyvoj a pak neumi ani triviality, ktere umely opravdova IDE roky (desetileti spis) zpet a reagovat tim, ze to neni potreba, protoze prece opravdovy programator to pise tak, ze to nikdy nebude treba refaktorovat a ze se nikdy nezmeni zadani a dalsi podobne bludy... To mozna funguje na malych projektech v jednom cloveku, i tak si myslim, ze to akorat povede k prasecimu kodu, protoze se nepouziva nastroj, ktery refaktorovani pohodlne zvlada, takze to programator rucne delat nebude a nejak si to ospravedlni.
Ať si každý používá co chce. Ale hlásat, jak je IDE nejlepším nástrojem na vývoj a pak neumí triviality, které uměly opravdové editory roky (spíš desetiletí) a reagovat tím, ře to není potřeba, protože opravdový programátor píše tak, že takový redesign může dělat každou chvíli a že se každou chvíli změní zadání a další podobné bludy...
Přejmenování třídy nebo metody opravdu není refaktorování. To jen autoři IDE nám věší bulíky na nos.
-
Ale hlásat, jak je IDE nejlepším nástrojem na vývoj a pak neumí triviality
Urcite IDE zjednodusuje pracu a to vo velkom.
-
Chci tím říct, že
a) bez command line se neobejdeme, ani kdyby se frikulíni s jejich klikátkma na přirození stavěli
b) program, co nemá možnost ovládání přes CLI, jako tool pro vývoj neobstojí ani náhodou
c) že moje osobní zkušenost je taková, že kdo nemá mentální kapacitu na zapamatování pár klávesových zkratek a pár příkazů na konzole, ten nemá na 99% mentální kapacitu ani na to, aby napsal program dobře (chybí výjimky, validace, ...). Což ale samozřejmě neznamená, že zdatný uživatel command line napíše dobrý programy.
d) nikdy nenechávej narcistu programovat něco, co budou používat ostatní.
To je všechno hezké, ale úplně mimo téma. Jo, chápu že tě evidentně Winowsáci točí, ale nevšiml jsem si že by se tady takový objevil (koneckonců - co by tu dělal, že).
A nebo si fakt myslíš že platí ekvivalence (nebo i implikace) mezi "používá IDE pro psaní kódu" a "nepoužívá command line"? Mimo Windows svět rozhodně ne - a i tam se už časy hodně mění (už jenom z toho důvodu, že automatizace buildů a testů je dnes v podstatě standard).
-
Jak chceš nepoužívat konzolu, když jsi připojen přes SSH k serveru, na kterém není Xclient?
A to je programovani? Vzdyt si to stahnu z gitu, programuji lokalne, pushnu, deploy. Teda aspon tak to delaj normalni programatori a ne amatersti pristipkari pres ssh.
Dělám sběr dat na elektrárnách v Rumunsku, Srbsku, na Ukrajině a v Polsku u Baltického moře. K dispozici tam mám počítač výkonem cosi pod úrovní maliny a přístup jen přes SSH. Pokud mám štěstí, jsem připojený drátem a ne přes geostacionární satelit. Proprietární protokol je pokaždé nějaký jiný, bez přímé komunikace se zařízením se to udělat nedá, za obrovskou standardizaci se dá považovat modbus. Mám si teda nechat přivézt elektrárnu k sobě do kanceláře? Nebo bude lepší zajet třeba na Ukrajinu, usadit se s notebookem uprostřed rozbahněného pole a programovat tam? A v Rumunsku jak? Pravou rukou budu klikat myší a levou klackem odhánět místní magnetické obyvatelstvo?
-
Možná si najít něco na západě za pořádné peníze 8)
Jinak nechápu, proč pořád reagujete na Kitovo trollení. VIM se na vývoj nepoužívá, protože je to neefektivní. Pokud si on doma něco patlá a je každému jedno, jestli to dělá 10 nebo 100 hodin, protože jeho hodina je stejně max za 600,-, tak proč ne. Ale dnešní vývoj musí mít trochu rychlost a tohle jsou tak osmdesátky, kde i kvalita vývoje byla odlišná.
-
Jinak nechápu, proč pořád reagujete na Kitovo trollení. VIM se na vývoj nepoužívá, protože je to neefektivní. Pokud si on doma něco patlá a je každému jedno, jestli to dělá 10 nebo 100 hodin, protože jeho hodina je stejně max za 600,-, tak proč ne. Ale dnešní vývoj musí mít trochu rychlost a tohle jsou tak osmdesátky, kde i kvalita vývoje byla odlišná.
DNFTT!
Kvalita vývoje jde s IDE brutálně dolů, protože v něm dělá i kdejaký patlal.
-
Jinak nechápu, proč pořád reagujete na Kitovo trollení. VIM se na vývoj nepoužívá, protože je to neefektivní. Pokud si on doma něco patlá a je každému jedno, jestli to dělá 10 nebo 100 hodin, protože jeho hodina je stejně max za 600,-, tak proč ne. Ale dnešní vývoj musí mít trochu rychlost a tohle jsou tak osmdesátky, kde i kvalita vývoje byla odlišná.
DNFTT!
Kvalita vývoje jde s IDE brutálně dolů, protože v něm dělá i kdejaký patlal.
Takže pokud dělám v IDE a jsem cca desekrát rychlejší než ty, tak pokud nějaký patlal dělá v IDE, tak mě to také zpomaluje? WTF?
-
Kvalita vývoje jde s IDE brutálně dolů, protože v něm dělá i kdejaký patlal.
v com ide kvalita dole? Co napr. take pripojenie na DB, otestovanie konekcie, vytvorenie objektov z DB, to vsetko ide cez VS na par klikov. VIM nepouzivam, ale neviem si celkom predstavit, ako by tam bolo nieco taketo mozne realizovat. Ale stavim sa, ze v tom IDE VS to spravim ovela rychlejsie.
-
Jinak nechápu, proč pořád reagujete na Kitovo trollení. VIM se na vývoj nepoužívá, protože je to neefektivní. Pokud si on doma něco patlá a je každému jedno, jestli to dělá 10 nebo 100 hodin, protože jeho hodina je stejně max za 600,-, tak proč ne. Ale dnešní vývoj musí mít trochu rychlost a tohle jsou tak osmdesátky, kde i kvalita vývoje byla odlišná.
DNFTT!
Kvalita vývoje jde s IDE brutálně dolů, protože v něm dělá i kdejaký patlal.
Takže pokud dělám v IDE a jsem cca desekrát rychlejší než ty, tak pokud nějaký patlal dělá v IDE, tak mě to také zpomaluje? WTF?
Když píšeš v IDE 10× rychleji než já, napíšeš i 10× víc zbytečného kódu a víc než 10× více chyb. Čtení tvého kódu zabere 10× víc času, než toho mého. Kód se čte 10× častěji než se píše. Kde je ta efektivita?
-
Kvalita vývoje jde s IDE brutálně dolů, protože v něm dělá i kdejaký patlal.
v com ide kvalita dole? Co napr. take pripojenie na DB, otestovanie konekcie, vytvorenie objektov z DB, to vsetko ide cez VS na par klikov. VIM nepouzivam, ale neviem si celkom predstavit, ako by tam bolo nieco taketo mozne realizovat. Ale stavim sa, ze v tom IDE VS to spravim ovela rychlejsie.
Připojení na DB mám za pár sekund včetně otestování spojení a vytváření objektů z DB je běžnou rutinou. To sis nevybral zrovna reprezentativní příklady, kde by IDE mohlo být rychlejší.
-
takze mi chces nahovorit, ze vo VIMe, ktory je primarne textovy editor spravis automaticke pripojenie na DB, povytvaranie objektov atd. :D A este mi prosim Ta povedz, kolko pluginov musis mat k tomu nainstalovanych? Popr. take, ze AttachToProcess, spustenie emulatoru (vo VS je to len prepnutie v jednom comboboxe). Co taka analyza kodu, zistenie cyklomatickej zlozitosti?
Uz si bol parkrat dotazany na ukazku svojich prac, ale stale sa nikto nedockal.
-
takze mi chces nahovorit, ze vo VIMe, ktory je primarne textovy editor spravis automaticke pripojenie na DB, povytvaranie objektov atd. :D A este mi prosim Ta povedz, kolko pluginov musis mat k tomu nainstalovanych? Popr. take, ze AttachToProcess, spustenie emulatoru (vo VS je to len prepnutie v jednom comboboxe). Co taka analyza kodu, zistenie cyklomatickej zlozitosti?
Uz si bol parkrat dotazany na ukazku svojich prac, ale stale sa nikto nedockal.
Ano, přesně tak. URL na ukázky svého kódu jsem už zveřejňoval několikrát, najdi si to.
Pluginy se píší poměrně snadno (je to v objektovém jazyce) a hotových pluginů najdeš na netu mraky - Vim Script je 10. nejrozšířenějším programovacím jazykem.
-
Dělám sběr dat na elektrárnách v Rumunsku, Srbsku, na Ukrajině a v Polsku u Baltického moře. K dispozici tam mám počítač výkonem cosi pod úrovní maliny a přístup jen přes SSH. Pokud mám štěstí, jsem připojený drátem a ne přes geostacionární satelit. Proprietární protokol je pokaždé nějaký jiný, bez přímé komunikace se zařízením se to udělat nedá, za obrovskou standardizaci se dá považovat modbus. Mám si teda nechat přivézt elektrárnu k sobě do kanceláře? Nebo bude lepší zajet třeba na Ukrajinu, usadit se s notebookem uprostřed rozbahněného pole a programovat tam? A v Rumunsku jak? Pravou rukou budu klikat myší a levou klackem odhánět místní magnetické obyvatelstvo?
To je docela zajímavé. Sběr dat chápu, ale proč se to musí pokaždé programovat znova? Že by každý měsíc vyměnili čidla? To se mi nějak nezdá... Každopádně, klobouk dolů, to chce nervy psát a ladit program přímo na živém HW takového kalibru, to bych si nelajznul.
-
Dělám sběr dat na elektrárnách v Rumunsku, Srbsku, na Ukrajině a v Polsku u Baltického moře. K dispozici tam mám počítač výkonem cosi pod úrovní maliny a přístup jen přes SSH. Pokud mám štěstí, jsem připojený drátem a ne přes geostacionární satelit. Proprietární protokol je pokaždé nějaký jiný, bez přímé komunikace se zařízením se to udělat nedá, za obrovskou standardizaci se dá považovat modbus. Mám si teda nechat přivézt elektrárnu k sobě do kanceláře? Nebo bude lepší zajet třeba na Ukrajinu, usadit se s notebookem uprostřed rozbahněného pole a programovat tam? A v Rumunsku jak? Pravou rukou budu klikat myší a levou klackem odhánět místní magnetické obyvatelstvo?
To je docela zajímavé. Sběr dat chápu, ale proč se to musí pokaždé programovat znova? Že by každý měsíc vyměnili čidla? To se mi nějak nezdá... Každopádně, klobouk dolů, to chce nervy psát a ladit program přímo na živém HW takového kalibru, to bych si nelajznul.
Ono se to nemusí programovat furt znova. Ale spravujeme takhle asi čtyřicet elektráren a i když je to většinou osazené stejnými střídači, je to docela slušná sbírka různého hw. Občas se i něco změní - přestane být podporovaný nějaký starší hw (převodník, komunikační prvek) a je potřeba se přizpůsobit. Různých drobností se najde i bez změny hw spousta. Naposledy jsem řešil filtraci signálů na jedné elektrárně - do halových sond na měření proudu se indukovaly nějaké rušivé špičky, které ovlivňovaly měření.
Zatím nejhorší zážitek byla tuším nějaká rumunská elektrárna. Na místě byl kolega, který všude byl a všemu rozuměl a střídače jsme nebyli schopní několik týdnů donutit k rozumné komunikaci. Pak jsme zjistili, že majitel nezaplatil za střídače a ty byly uvedené do stavu "trucujeme".
-
Takže se vim nevyplatí učit? Ani jako jeho emulátor v IDE?
-
Takže se vim nevyplatí učit? Ani jako jeho emulátor v IDE?
Pokud se někdo chce ptát na práci s Vimem, nechť si založí nové vlákno. Tady jsme toho už zaplevelili dost.
Obávám se, že emulátor Vimu v IDE neumí skoro nic, pouze editovat. Není tedy vhodné s ním začínat a je lepší sáhnout po plné verzi.
-
1. Defaultný font Visual Studia, VS Code alebo Atomu.
2. Zalamuji podle logickosti.
3. Ne a mám dve monitory, skrz ktoré kód mohu vidieť
4. Jedine Dark
5. Záleží od situace
6. Ano
7. Space (veľkosť záleží od situace)
8. Záleží od situace.
-
1. Jaky font pouzivate pri programovani ? (Teď už skoro na vše používám IDE Eclipse a tam je v defaultu Consolas 10px)
2. Za kterym sloupcem zalamujete ? (Tohle záleží na týmu a jak se dohodnou, většinou 100, nebo 120. Ono to je důležité mít to všichni stejně kvůlivá code review. V diffu to pak vypadá blbě.)
3. Mate monitor s editorem otoceny na vysku ? (Ne)
4. Tema - dark / light ? (stále light, dark jsem používal před lety, myslel jsem, že to vypadá víc hackersky a je to blbost)
5. Pripadne shell prikazy spoustite z editoru/IDE nebo terminalu ? (Jak co. Co jde z IDE to z IDE, místo kalkulačky mám IDLE Python, jinak klasicky stále otevřen terminál, nebo cmd)
6. Vyuzivate numericky blok klavesnice ? (ano)
7. Tab nebo space a kolik znaku ? (Záleží na jazyku, ale teď už i v Java 4x space, v Python je to standard u ostatních už to používám taky)
8. blokovou { davate pod prikaz nebo vedle nej ? (vedle, ale zase, je třeba mít to stejně jako zbytek týmu)
U toho formátování obecně je důležité mít jeden formatter file pro všechny a nutit je všechny to používat. Když si jeden píše jenom sám, tak bych doporučil odrazit se od standardních formatters pro daný jazyk a ten si přizpůsobovat.
K debatě o Vim, komu hrozí, že se bude připojovat přes SSH na linux, ten by se ho měl naučit, protože ho prostě všude najde a je to dobrý editor. K programování používám velká IDE. Protože např. Java je děsně ukecaná a bez kvalitního autocomplete a nástrojů na refaktor, formátování kódu, organizaci importů, generování getters, setters a dalších a dalších pomůcek bych se asi upsal a především bych byl pomalejší.
A co se pro Eclipse objevil kvalitní Toad tak už i pro práci se SQL servery používám Eclipse. UML modeling taktéž v Eclipse. Tomcat spravuji tamtéž, Maven taky....no už toho moc nezbývá co bych dělal mimo IDE.
-
Používám nejlepší IDE na světě, IDEU, a formátuji tak, jak ona formátuje. Kolegové to používají rovněž a proto to máme stejně. Kdybych dělal v 2. nejlepším IDE na světě, Visualku, dělal bych to tak samo. Kdybych dělal v jiném IDE, tak bych šel raději pást krávy nebo ovce do hor a měl bych pěkně klid.
Zalamování je nutné, kdo nezalamuje tak je amatér nebo nepoužívá GIT.
-
Používám nejlepší IDE na světě, IDEU, a formátuji tak, jak ona formátuje. Kolegové to používají rovněž a proto to máme stejně. Kdybych dělal v 2. nejlepším IDE na světě, Visualku, dělal bych to tak samo. Kdybych dělal v jiném IDE, tak bych šel raději pást krávy nebo ovce do hor a měl bych pěkně klid.
Zalamování je nutné, kdo nezalamuje tak je amatér nebo nepoužívá GIT.
Běžný editor také umí formátovat podle pravidel projektu. Stačí ho jen nastavit. Kromě toho se dají tato pravidla nastavit i v repozitáři Gitu. Vývojář pak může zdroják klidně naprasit na jeden řádek, ale v repozitáři je perfektní.
Zalamování není nutné, pokud píšeš krátké řádky, max. 4 úrovně odsazení a používáš proměnné místo komentářů. Jinak viz výše.
-
Používám nejlepší IDE na světě, IDEU, a formátuji tak, jak ona formátuje. Kolegové to používají rovněž a proto to máme stejně. Kdybych dělal v 2. nejlepším IDE na světě, Visualku, dělal bych to tak samo. Kdybych dělal v jiném IDE, tak bych šel raději pást krávy nebo ovce do hor a měl bych pěkně klid.
Zalamování je nutné, kdo nezalamuje tak je amatér nebo nepoužívá GIT.
Běžný editor také umí formátovat podle pravidel projektu. Stačí ho jen nastavit. Kromě toho se dají tato pravidla nastavit i v repozitáři Gitu. Vývojář pak může zdroják klidně naprasit na jeden řádek, ale v repozitáři je perfektní.
Zalamování není nutné, pokud píšeš krátké řádky, max. 4 úrovně odsazení a používáš proměnné místo komentářů. Jinak viz výše.
Ono ani ty pocitace nejsou nutne vis, staci past ovce, kravy, delat syr, brynzu (Slovaci by mohli povidat), v lete se daji zrat i pampelisky. Nadsvetelnou rychlosti se stejně nedá cestovat, nikdy se nepodivame do jineho solarniho systemu, tak proč nepást jen ty ovce? Vzdyt to taky neni tak spatny, s peknou holkou na kline.
-
Tebe neunavuje vymyslet cinvytvaret jiz x-krat vymyslene/vytvorene? Me celkem jo, porad vyvoj veci jak pres kopirak. Nekdo uz nastavil pekne formatovani a pouzivaji to skoro vsichni, proc si nastavovat svoje?