Code automatisch einfügen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Code automatisch einfügen

    Folgende Frage:
    Wenn ich in einem *.h file einige Methoden erzeuge, ist es möglich, dass mir Xcode in der zugehörigen *.m Datei die Methodenrümpfe bereits einfügt?
    Bzw. Wenn ich diverse Protokolle implementiere, auch hier wäre es toll, wenn bereits die Methodenrümpfe in der *.m-Datei eingefügt werden.

    Habe bisher sehr viel mit Eclipse gearbeitet, da funktionieren solche Dinge sehr gut, bin daher ein wenig verwöhnt. :)

    Alex

  • Das finde ich jetzt aber mal sehr sehr spannend.

    Warum wird das als Defizit der IDE angesehen?
    Wofür wird das benötigt?

    Ich persönlich bekomme bei vorausgefüllten Dummy-Einträgen immer eine mittelschwere Krise.
    Was fällt dieser Scheiß-IDE (namentlich Eclipse) eigentlich ein, meinen Sourcecode mit unsinnigen leeren Implementierungen irgendwelcher Interfaces, Parents oder wasweißichnicht vollzumüllen?
    Idealerweise wirft der mir dann noch überschreibbare Methoden rein, die ich überhaupt nicht überschreiben will – was soll das?

    Wenn ich jede benötigte Methode einzeln selbst anfassen muss (und da wird mir ja eh schon alles Wichtige vorgeschlagen), dann mache ich mir auch mehr Gedanken um diese jede einzelne Methode.

    Ja, solange ich nicht jede einzelne benötigte Methode selbst eingegeben habe, kompiliert der Code nicht.
    Braucht er auch nicht, das Objekt ist ja noch nicht einmal ansatzweise fertig.
    (Schließlich habe ich nicht jede einzelne benötigte Methode selbst eingegeben)

    Wenn hingegen der Code gleich nach der ersten Erstellung erfolgreich kompiliert, dann ist unersichtlich, welche Methoden jetzt schon das tun was sie sollen und welche nicht.

    Wenn jemandem Xcode nicht passt, kann er ja immer noch AppCode nehmen.
    (Ja, die kostet über 150€… Wem auch das nicht passt, der kann ja Eclipse um Objective-C Fähigkeiten erweitern.)

    Mal ganz davon abgesehen, dass man bei Einhaltung des TDD eh immer nur eine (öffentliche) Methode schreibt und die nächste öffentliche Methode erst dann beginnt, wenn alle Tests für diese eine Methode erfolgreich waren.
    Nix mit 'ich notier schon mal die Methodensignatur und implementier dann später'.
    Zumal 'später' auch ziemlich oft mal 'nie' wird – bei mir zumindest.

    Aber nach wie vor interessiert mich brennend, wofür dieses Feature benötigt wird.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Natürlich soll die IDE nicht automatisch alle Methodenrümpfe einfügen. Ich wusste nicht, dass Eclipse soooo schlecht ist. ;)

    Man kann das auch geschickter machen; z. B. wie IntelliJ (bzw. wahrscheinlich auch AppCode): Dort drückst du eine Tastenkombination und die IDE bietet dir eine Liste der Methoden an, die du überschreiben beziehungsweise implementieren kannst. Du wählst dann die gewünschten Methoden aus und drückst OK. Das ist sehr praktisch. :)
    „Meine Komplikation hatte eine Komplikation.“

  • Ne, ich muss sagen, das vermisse ich auch etwas. Muss ja nicht automatisch sein, aber per Tastenkürzel Rumpf-Implementierungen von noch fehlenden Methoden erzeugen zu können wäre fein.

    Aber mei, das ist halt Xcode. Da bin ich ja schon froh wenn der SourceKit-Service nur all 5 Minuten abkachelt und anschließend keine Code-Vervollständigung mehr geht. Und nicht jede Minute. Mein Ordner "Diagnostics Reports" quillt über mit entsprechenden Crash-Logs

    Apropos Code-Vervollständigung. Geht das nur mir so, oder findet die noch jemand so schlecht? Vor allem seit sie auf clang umgestellt wurde? Wenn ich irgendwo beim Programmieren ein klitzekleines Tippfehlerchen habe, hängt an der Stelle der Compiler und ich bekomme danach keine Code-Vervollständigung mehr (Na ja, es kommt schon nach was, aber nur lächerliche Vorschläge). Also muss ich meinen momentanen Gedankenfluß unterbrechen, zu meinem Tippfehler zurück, das korrigieren und wieder nach vorne. Nervt mich jedesmal von neuem an. :cursing:

    Andere IDEs können das besser.

    schönen Gruß

    gandhi

  • macmoonshine schrieb:

    Natürlich soll die IDE nicht automatisch alle
    Man kann das auch geschickter machen; z. B. wie IntelliJ (bzw. wahrscheinlich auch AppCode): Dort drückst du eine Tastenkombination und die IDE bietet dir eine Liste der Methoden an, die du überschreiben beziehungsweise implementieren kannst. Du wählst dann die gewünschten Methoden aus und drückst OK. Das ist sehr praktisch. :)


    Das waren noch Zeiten :) Visual Studio 2012 <3
    Every language has an optimization operator. In ObjC that operator is ‘//’.

    golbros.de

  • gandhi schrieb:

    Da bin ich ja schon froh wenn der SourceKit-Service nur all 5 Minuten abkachelt und anschließend keine Code-Vervollständigung mehr geht.

    Nutzt Du etwa Swift mit dem Cocoa Framework?
    Wie naiv. ^^

    Ehrlich gesagt habe ich absolut keine Probleme mit dem SourceKit Service.
    Weder in Objective-C mit Cocoa noch in plain Swift.

    Allerdings lasse ich auch noch die Finger von Swift mit Cocoa.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    gandhi schrieb:

    Da bin ich ja schon froh wenn der SourceKit-Service nur all 5 Minuten abkachelt und anschließend keine Code-Vervollständigung mehr geht.

    Nutzt Du etwa Swift mit dem Cocoa Framework?
    Wie naiv. ^^

    Ehrlich gesagt habe ich absolut keine Probleme mit dem SourceKit Service.
    Weder in Objective-C mit Cocoa noch in plain Swift.

    Allerdings lasse ich auch noch die Finger von Swift mit Cocoa.


    habe ich mit Objective-C + Cocoa Touch + C++ am laufenden Band...
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io

  • Marco Feltmann schrieb:

    Aber wofür denn?


    Weil ich faul bin :D

    Weder in Objective-C mit Cocoa noch in plain Swift.​

    Swift-Framework, welches eine statische Objective-C Lib verwendet. Nix Cocoa, nur ein bißchen Foundation im ObjC-Framework. In dem Zusammenhang: Die Swift-Compiler-Fehler machen mich nochmal verrückt. Haben oft (eigentlich fast immer) mit dem eigentlichen Problem nix zu tun. Am schlimmsten wird's wenn der Compiler aufgrund der tollen type-inference auf einen falschen Typ schliesst und dann entsprechend sinnentleerte Meldungen ausspuckt. <X Mal gucken, wenn ich lustig bin, stell' ich mal ein "Best-of" zusammen. So als allgemeine Erheiterung.

    Gruß

    gandhi

  • Marco Feltmann schrieb:


    Wenn jemandem Xcode nicht passt, kann er ja immer noch AppCode nehmen.
    (Ja, die kostet über 150€… Wem auch das nicht passt, der kann ja Eclipse um Objective-C Fähigkeiten erweitern.)


    Wobei ich ehrlich gesagt den Hype im AppCode nicht nachvollziehen kann. Das ist mal wieder so eine Virtualisierungsebene zusätzlich, die *ganz nett* ist, mehr aber auch nicht. Xocde ist schon rock solid. Nur müsste Apple vielleicht mal ein paar Entwickler von dem "200-brandew-awesom-boom-Features"-Implementierungsteam abziehen und in die Bugfix-Truppe stecken. Der Xcode-Server ist eine einzige Krankheit, und Xcode knirscht auch noch an ziemlich vielen Ecken.

  • Ach, da gibt es noch einiges zu verbessern: Diese gemischte Objective-C-Swift-Doku ist schwierig zu lesen. Der Code-Formatierer ist auch nicht gerade komfortabel.

    kmr schrieb:

    Wobei ich ehrlich gesagt den Hype im AppCode nicht nachvollziehen kann. Das ist mal wieder so eine Virtualisierungsebene zusätzlich, die *ganz nett* ist, mehr aber auch nicht.

    Aus diesem Grund bin ich auch nicht umgestiegen: Die Einarbeitung in eine neue IDE kostet auch immer einiges an Zeit und Nerven. Bei einer Wrapper-IDE ist mir das Risiko zu hoch: Wenn man sich das Tool endlich gekauft und sich daran eingewöhnt hat, schmeißt Apple ein neues Xcode auf den Markt und nichts geht mehr. :(
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Ach, da gibt es noch einiges zu verbessern: Diese gemischte Objective-C-Swift-Doku ist schwierig zu lesen. Der Code-Formatierer ist auch nicht gerade komfortabel.

    kmr schrieb:

    Wobei ich ehrlich gesagt den Hype im AppCode nicht nachvollziehen kann. Das ist mal wieder so eine Virtualisierungsebene zusätzlich, die *ganz nett* ist, mehr aber auch nicht.

    Aus diesem Grund bin ich auch nicht umgestiegen: Die Einarbeitung in eine neue IDE kostet auch immer einiges an Zeit und Nerven. Bei einer Wrapper-IDE ist mir das Risiko zu hoch: Wenn man sich das Tool endlich gekauft und sich daran eingewöhnt hat, schmeißt Apple ein neues Xcode auf den Markt und nichts geht mehr. :(


    Genau das problem hatte ich anfangs mit AppCode + Xcode 6... Ich muss dazu sagen, es war die Xcode 6 DP, aber es hat trotzdem genervt... Außerdem konnte AppCode vis vor nicht all zu langer zeit nicht eigenständig Storyboards und der gleichem bearbeiten... Als Schüler taten mit die EDU-Kosten nicht solo weh, dass ich es bereue... benutzt wird AppCode von mir allerdings nicht.
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io

  • macmoonshine schrieb:

    Wenn man sich das Tool endlich gekauft und sich daran eingewöhnt hat, schmeißt Apple ein neues Xcode auf den Markt und nichts geht mehr.

    Wobei ich in dem Zusammenhang gehört habe, dass die Jungs von IntelliJ arg schnell sind, was das Nachpflegen der Features angeht.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • DanielBocksteger95 schrieb:

    habe ich mit Objective-C + Cocoa Touch + C++ am laufenden Band...

    Dafür nimmt man ja auch Objective-C++ statt Objective-C.
    Schon mal versucht, C mit Java zu verknüpfen? Ist ein ähnliches Chaos trotz (oder Dank?) JNI.
    Die Konzepte sind grundweg verschieden, du stopfst was dynamisch schwach typisiertes mit fetter Laufzeitumgebung in was statisch streng typisiertes mit fettem Compiler beziehungsweise umgekehrt.
    Hat so ein bisschen was von diesen Lern-Holzspielzeugen: Grundgerüst mit 3x runder Öffnung von 10cm Durchmesser und 8x Würfel mit einer Kantenlänge von 10cm, die alle da rein sollen.
    Geht. Nur nicht so leicht. Und es bleibt Späne über.

    gandhi schrieb:

    Swift-Framework, welches eine statische Objective-C Lib verwendet. Nix Cocoa, nur ein bißchen Foundation im ObjC-Framework.

    Also mischt Du Objective-C mit Swift.
    Die Integration der appleeigenen Frameworks mit Swift ist eine Katastrophe. Unter Anderem weil die Konzepte so unterschiedlich – nahezu gegensätzlich – sind.
    Aus welchem Grund sollte das besser klappen, wenn man das selbst versucht? Die Konzepte der implementierenden Programmiersprache und die der eingebetteten Programmiersprache ändern sich ja nicht dadurch, dass man die selbst verknüpft.

    Es hat so ein bisschen was von der ewigen C++/SDL vs Objective-C/keine SDL Diskussion…
    Objective-C ist eine Sprache, die einfach mal ganz großartig ist. Sie hat keine eigenen Datentypen, für Strings, Collections, etc.pp. Nur die C-üblichen int/float/double/void*/struct.
    Swift ist eine Sprache, die ganz ordentlich ist. Sie hat eigene Datentypen für Strings, Collections, etc.pp. Also quasi eine SDL.

    Der ganze App-Scheiß läuft über das Framework. Foundation, AppKit, was auch immer.
    Diese sind ursprünglich in Objective-C geschrieben, arbeiten mit Objective-C Datentypen, mit Objective-C Design Pattern und mit Objective-C Eigenarten.
    Der ganze NS Krams aus AppKit existiert seit 10.0, der ersten Mac OS Version mit Objective-C. Ebenso Foundation. Und der Framework Wrapper Cocoa. Das ist mit Sicherheit noch nicht alles auf Swift portiert.

    Das ist in Etwa so, als hätte man das .Net Framework so umgebogen, dass es sowohl mit C# als auch mit Python funktioniert…
    (Klar, geht. Die Entwickler der beiden meist verbreiteten Bridges basteln ja auch nur seit Mitte 2006 daran rum…)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • schneal76 schrieb:


    Wobei ich in dem Zusammenhang gehört habe, dass die Jungs von IntelliJ arg schnell sind, was das Nachpflegen der Features angeht.


    Von Juni bis Oktober hantiert der gemeine Entwickler sowieso nur mit Xcode-Betaversionen rum, da frage ich mich, wie die das sinnvoll zeitnah abbilden wollen. ;)

  • Marco Feltmann schrieb:

    Also mischt Du Objective-C mit Swift.

    Ja, genau. Und Apple sagt: "geht, kein Problem". Das Problem sind auch weniger die konzeptionellen Unterschiede zwischen Objc-C und Swift sondern schlicht und einfach das verbuggte Xcode 6. Das ist von Produktionsreife soweit entfernt, wie die Norddeutschen vom guten fränkischen Bier ;) (*)

    Der ganze NS Krams aus AppKit existiert seit 10.0, der ersten Mac OS Version mit Objective-C.

    Viel, viel älter. Das Zeugt kommt von NextStep (Deswegen "NS"!) aus Ende der Achziger, Anfang der Neunziger. Ich hab' hier noch ein Buch aus der Zeit zum Thema "Entwickeln mit Project-Builder, Interface-Builder für Nextstep".

    ciao

    gandhi
    (*) Gerade habe ich das Problem, dass der Swift-Compiler sich ab und zu weigert eine Objective-C enum zu kennen. Dann krittelt man ein bißchen im Source. Fügt hier ein Leerzeichen ein, benennt da eine Variable um und Schwups kennt er es wieder. Um's mit Einstein zu sagen: "Gott würfelt nicht, aber der Swift-Compiler".