Online IDE pro Javu s možností debugování

[Kit]

Jasne. A trebas strejda Bob bude prase nejvetsi.

Proč označuješ strejdu Boba za prase? Co ti provedl?

Sarkasmus.

Už vím, co ti provedl. Zakázal ti používat gettery a settery:

Why, then, do so many programmers automatically add getters and setters to their objects, exposing their private variables as if they were public?
...
The worst option is to blithely add getters and setters.
...
... have private variables manipulated by getters and setters. The quasi-encapsulation of beans seems to make some OO purists feel better but usually provides no other benefit.

[Reklama]

[gl]

To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.

Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.

Mám na mysli situaci, kdy při práci na commitu provedu hodně přejmenování např. v rámci nového kódu.

Dustin mluvil o stovkách commitů od každého vývojáře.

[Tuxik]

Proč myslíte, že odpadá? Když má featura tisíce řádků (např. se na ní pracuje několik let), tak ta přejmenování mohou být poměrně složitá.

Takže celé roky pracuješ nad svým forkem? Nebo to commituješ do develu, kterej se nedostane do mainu a nemáš potřebu nikomu sdělit, co děláš? Nebo to commituješ do mainu a opět v commitech neříkáš, co děláš a kód se nepoužívá? Nebo jakým způsobem se stane, že nikomu nesdělíš, co provádíš se svou roky vyvíjenou fičurou?

[gl]

Myslíš tohle?

https://github.com/python-rope/rope/blob/master/docs/overview.rst#move-method-refactoring

Ne, myslím tohle:

Kód: [Vybrat]

class Child(object):

    def a_method(self):
        pass

    def b_method(self):
        pass

child1 = Child()
child1.a_method()

child2 = Child()
child2.a_method()
child2.b_method()

Po refaktorování:

Kód: [Vybrat]

class Parent(object):

    def a_method(self):
        pass

class Child(Parent):

    def b_method(self):
        pass

parent1 = Parent()
parent1.a_method()

child2 = Child()
child2.a_method()
child2.b_method()


Dosud jsme se bavili o prostém přejmenování funkce. K tomu stačí jednoduší nástroje.

O pouhém přejmenování se asi baví jenom ti, kteří tvrdí, že si vystačí s regulárními výrazy. A navíc tu pořád nikdo neukázal, jak bude pomocí regulárního výrazu automaticky přejmenovávat metodu, když stejně pojmenovanou metodu bude mít v desítkách dalších tříd.

Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.

Snadné zjistit? Tím regexpem? Nebo budete třeba stovky výskytů procházet očima? Jaká je v tom výhoda?

Pro tohle bych si mohl napsat funkci pomocí jedi a rope api. Ale nedovedu si představit situaci, kdy bych to potřeboval. Kdybych přejmenoval všechno na parent, tak mi flycheck červeně podtrhne to použití b_method. Chyba tedy nehrozí.

[Filip Jirsák]

Pro tohle bych si mohl napsat funkci

Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?

[Reklama]

[gl]

Pro tohle bych si mohl napsat funkci

Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?

Výhoda to není.

[Tuxik]

Pro tohle bych si mohl napsat funkci

Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?

Jaká je výhoda toho, si něco nechat programovat na míru, když absolutní většina věcí už se dá řešit existujícími nástroji?

[Radek Miček]

Proč myslíte, že odpadá? Když má featura tisíce řádků (např. se na ní pracuje několik let), tak ta přejmenování mohou být poměrně složitá.

Takže celé roky pracuješ nad svým forkem? Nebo to commituješ do develu, kterej se nedostane do mainu a nemáš potřebu nikomu sdělit, co děláš? Nebo to commituješ do mainu a opět v commitech neříkáš, co děláš a kód se nepoužívá? Nebo jakým způsobem se stane, že nikomu nesdělíš, co provádíš se svou roky vyvíjenou fičurou?

Kód se třeba roky vyvíjí v rámci pull requestu mimo hlavní větev - komunita může dělat review a až je vše připraveno, squashne se kód do několika desítek commitů.

To bohužel neříká, kolik přejmenování proběhlo předtím, než se commit dostal do upstreamu.

Takže přejmenování je taková prkotina, že vlastně ani nestojí za to to napsat do commitu? To jako něco přejmenuješ, něco přidáš, něco smázneš a do commitu napíšeš "next commit"? Tak to jo, to je spolupráce radost.

Mám na mysli situaci, kdy při práci na commitu provedu hodně přejmenování např. v rámci nového kódu.

Dustin mluvil o stovkách commitů od každého vývojáře.

Například pracovní verze https://github.com/ocaml/ocaml/pull/132 měla přes 1200 commitů, tyto commity se však nemergovaly - místo toho se vytvořily jiné, kterých bylo mnohem méně.

[Radek Miček]

Sorry, v předchozím příspěvku jsem nechtěl citovat gl - celá odpověď patří Tuxikovi.

[Tuxik]

Takže co nejde do mainu se nekomentuje? Komunita může koukat, ale sama si musí dohledat co se změnilo a pomocí křišťálové koule odhadovat proč? Není to dost neefektivní?

[Kit]

Pro tohle bych si mohl napsat funkci

Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?

Výhoda to není.

Ale není to zas tak velká nevýhoda, kvůli které by programátor opouštěl své oblíbené vývojové prostředí.

[gl]

Uznávám, že PyCharm toho asi umí víc, ale takovouhle funkčnost by mne nenapadlo hledat. Celkově dědičnost používám velmi zřídka, a smysl téhle úpravy mi uniká. Může tam být případ, kdy bych chtěl použít Child, ale nepoužiji b_method, tak se mi to přejmenuje.

[Filip Jirsák]

Pro tohle bych si mohl napsat funkci

Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?

Výhoda to není.

Ale není to zas tak velká nevýhoda, kvůli které by programátor opouštěl své oblíbené vývojové prostředí.

Obávám se ale, že kvůli tomu ani ve svém oblíbeném prostředí nebude psát ten skript a raději kód nějak naprasí bez refaktoringu. Protože to je s jeho oblíbenými nástroji nejjednodušší řešení.

Pořád jde ale o to, co kdo píše. Pokud někdo píše nějaké algoritmy nebo struktury, typicky mění malou část kódu a důležité je pro něj hlavně psaní a editace kódu. Pokud zná Vim nebo Emacs, bude v nich efektivnější než s IDE. Pokud někdo potřebuje propojit spoustu komponent do jednoho celku (typická Java aplikace), potřebuje naopak pořádné IDE, protože nepotřebuje detailně znát nějaký kód, ale naopak potřebuje mít přehled o aplikaci na vyšší úrovni.

[gl]

Pro tohle bych si mohl napsat funkci

Jaká je výhoda v tom psát si na to vlastní funkci oproti využití již hotového nástroje?

Výhoda to není.

Ale není to zas tak velká nevýhoda, kvůli které by programátor opouštěl své oblíbené vývojové prostředí.

Obávám se ale, že kvůli tomu ani ve svém oblíbeném prostředí nebude psát ten skript a raději kód nějak naprasí bez refaktoringu. Protože to je s jeho oblíbenými nástroji nejjednodušší řešení.

Pořád jde ale o to, co kdo píše. Pokud někdo píše nějaké algoritmy nebo struktury, typicky mění malou část kódu a důležité je pro něj hlavně psaní a editace kódu. Pokud zná Vim nebo Emacs, bude v nich efektivnější než s IDE. Pokud někdo potřebuje propojit spoustu komponent do jednoho celku (typická Java aplikace), potřebuje naopak pořádné IDE, protože nepotřebuje detailně znát nějaký kód, ale naopak potřebuje mít přehled o aplikaci na vyšší úrovni.

V tomhle případě to přejmenuju všechno a kde bude pylint řvát, vrátím to zpět. Triviální úprava. Budu ji nejspíš dělat jen jednou za život. Není třeba k tomu mít speciální funkci.

[javaman (však vy víte)]

Takže co nejde do mainu se nekomentuje? Komunita může koukat, ale sama si musí dohledat co se změnilo a pomocí křišťálové koule odhadovat proč? Není to dost neefektivní?

Neverzuješ ty tím novým adresářem na sdíleném disku? U složitějšího třeba Git flow je to úplně normální. Nikoho nezajímá, co sis někde prasil, když si jen přidával něco konkrétního.