【问题标题】:non-XCode IDE for Cocoa?可可的非 XCode IDE?
【发布时间】:2009-06-15 12:13:55
【问题描述】:

我认为 Xcode 是一个很好的 IDE,但在过去使用 Eclipse 进行 Java 开发时,我对 XCode 的代码完成和错误/警告反馈感到非常失望。 (大多数时候,XCode 似乎只是尝试将文本片段的开头与同一文档中的“单词”匹配,甚至没有使用类型信息来尝试确定建议完成的适当性。)

有没有人有想法或技巧让 XCode 接近 Eclipse 的聪明才智,或者用除 XCode 之外的其他 IDE 实际开发 Cocoa 应用程序?

编辑:值得关注:code.google.com/p/objectiveclipse/

【问题讨论】:

  • 对于 iPhone 版 XCode 的替代品也有类似的问题,但由于 App Store 不会接受非基于 XCode 构建的应用程序这一事实,情况变得复杂。
  • 如何确定应用是使用哪个 IDE 构建的?
  • 对于对此主题感兴趣的人,我提供了 Accessorizer 实用程序的链接,它有助于 XCode 变得更智能:www.kevincallahan.org/software/accessorizer.html跨度>

标签: objective-c cocoa xcode


【解决方案1】:

好消息是,Apple 正在解决这个问题。 clang 编译器项目的目标之一是创建一个可重用的解析器,该解析器可用于更好的代码完成和重构支持。有迹象表明,这已经在最新的雪豹种子中结出了果实。

【讨论】:

  • Clang 是一个美丽的东西。 WWDC 的编译器部分几乎让我们中的一些人落泪。或者至少是很多掌声。
  • 啊,是的。我读过关于clang的文章,但忘记了。对于感兴趣的人,这里有一些有趣的背景:etoileos.com/news/archive/2009/03/31/1640 这也表明非 Apple 的 Objective-C/NS 派生的编码是活跃的。这已在其他地方讨论过 SO:stackoverflow.com/questions/874690/…
  • Apple 的 LLVM 和 Clang 目标(其中一些是长期目标)包括在几乎所有情况下完全取代 GCC。模块化设计允许可插拔前端(Clang 就是其中之一),并将解析与优化和代码生成完全分离。很高兴看到这种势头,而且这一切都是开源的这一事实甚至更好。
  • 对于那些现在渴望一些快速简单的clang善良的人,请查看:www.karppinen.fi/analysistool。强烈推荐!
【解决方案2】:

很简单:没有。

您几乎可以使用自己喜欢的文本编辑器手动完成所有操作,但完全不推荐这样做。例如,尝试在没有 Interface Builder 的情况下设计界面。

我的建议是坚持使用 Xcode 并学习其做事方式。是的,它会有所不同,有时在你 Eclipsed 眼中可能不会“更好”。安慰自己,Apple 设法使用 Xcode 发布了一些很棒的产品。

我个人的经验是,每次我使用 Xcode 时,我都会发现一个可以添加到我的包中的新技巧。 Xcode 的功能远比您第一眼(或第二眼)所想的要全面。

【讨论】:

  • 我注意到随着岁月的流逝,功能已稳步添加。 Eclipse、VisualStudio 等中仍有一些我嫉妒的特性,我希望在 Xcode 中看到它们(希望早点而不是晚点)。也就是说,Xcode 在某些领域也击败了其他 IDE。 Eclipse 的致命弱点可能是创建和管理项目和工作区,它是一个令人难以置信的屏幕空间,并且插件经常失控。我没有足够频繁地使用 VS 来挑选细节,但是当我使用它时,解决方案/项目配置肯定会令人困惑。
  • 我同意 Eclipse:每当我尝试使用超出核心功能的任何东西时,我都会感到沮丧。就像 Aptana 的 RadRails……那是一场噩梦。我什至在让 SCM 集成在 Eclipse 中正常工作时遇到了问题。但它在哪里闪耀,它肯定设定了一个标准。
  • 我曾经尝试安装 Eclipse 并将其用于 Ruby on Rails 开发。永远,永远。这是一场彻头彻尾的噩梦,我浪费了我生命中的许多天来试图让它发挥作用。它很慢,很麻烦,看起来很糟糕,而且插件设置起来也很糟糕。
【解决方案3】:

我早就表达了我的rants about what's wrong with Xcode(Xcode 没有什么问题)。但是您真的不想使用其他工具。在不破坏 NDA 的情况下:Xcode 3.2 with SnowLeopard:Hooray。 (与我们所拥有的相比;而不是与我们可能想要的相比。)

也就是说,对于您最初关于代码完成的问题,我个人关闭了自动完成以支持按需完成。我发现它更有用,更不会分散注意力。在 Code Sense 面板中,将“Automatically Suggest”设置为“Never”并确保选择了其他两个选项(“Show arguments in pop-up list”和“Insert argument placeholders...”)这将完成当您点击 Escape 时弹出框,可以轻松滚动查找您想要的内容。我发现我必须用这种方式打字少很多,特别是对于许多字符不是唯一的方法。 80% 的时间,它已经在强调正确的事情了。

【讨论】:

    【解决方案4】:

    我确实感受到了您的痛苦——作为一名经验丰富的 Java 开发人员和经常使用 Eclipse 的用户,我自己也希望拥有相同的功能。不幸的是,我不知道有什么符合要求的。我认为this SO question 也没有任何令人满意的解决方案。

    但是,我认为您会对 Snow Leopard 中对 Xcode 代码完成的改进感到非常满意 - 它在过滤可能的完成列表方面要聪明得多。此外,还有一些新的编码便利,例如当您忘记一个起始括号时插入一个起始括号等。据我所知,仍然没有像 Eclipse 这样的预测编译。

    是否有人知道除 Eclipse 之外支持预测编译和警告/错误报告的 IDE? Eclipse 本身是否支持 Java 以外的语言(例如 C++)的功能?我不禁想知道,Java 是用独立的 .java 文件而不是 .h 和 .c/.cpp/.m 文件构建的这一事实是否使得预测性编译变得更简单。此外,与相对简单的 javac 命令相比,使用 gcc 编译的任何内容都需要更多的关注和关注。有什么想法吗?

    【讨论】:

    • XCode 进行预测编译以提高构建性能。它只是不能很好地利用它收集的信息。我不相信除了 javac 之外的 gcc 编译需要任何特别的注意。每个 .o 都是独立编译的,因此在预测编译期间没有什么特别之处。
    • 我也在考虑是否有什么东西可以让 Java 在本质上比 Objective-C 更容易进行预测编译,但真的想不出任何东西(当然除了, 用于丧失类型安全性的动态 ObjC 代码)。正如 Ahruman 所建议的,阅读有关 Clang 的内容提供了更多上下文。
    • 非常正确。无论如何,Xcode 已经生成了 gcc 命令。似乎部分问题在于 gcc 本身——它在 GPL 下,这限制了 Apple 在不使 Xcode 本身开源的情况下真正无缝地集成它。动态类型甚至不会引起问题,因为您真正关心的是 Objective-C 上下文中的正确性,而不是 Java 或任何其他语言中的正确性。我认为随着 Clang 成为主流并最终在 Xcode 中取代 gcc,我们将看到类似的功能出现。 (期待那一天……)
    【解决方案5】:

    查看 JetBrains 的名为“App Code”的新 IDE。它仍处于抢先体验计划中,但即使存在抢先体验漏洞,它也比 xcode 4轻松

    http://www.jetbrains.com/objc/

    【讨论】:

      【解决方案6】:

      emacs 和/或 vim

      【讨论】:

      • 和/或 TextMate 和/或 KDevelop 或 [某人最喜欢的编辑器]。是的...但是如何鼓励建议使用特定的编辑器/IDE?
      • 我希望 喜欢 看到和 emacs/vim 爱好者支持这样的说法。没有代码(真正的)完成,更不用说预测编译了。文本编辑器只被认为 GUI 是一种最终会消亡的时尚的人认为是 IDE。 KDevelop 实际上是一个 IDE(用于 KDE),但它几乎不支持 Objective-C,更不用说高级编译功能了。
      • @Quinn 我想让你与 emacs/vim 专家(不是我)面对面交流,他们有大量的键盘快捷键、宏和插件。假设每个人都知道他们在做什么编程,我相信 emacs/vim 专家将能够通过鼠标点击围绕典型的 IDE 编写圆圈。 :-P 虽然另一方面,我确实喜欢 Firefox 作为 lynx 的替代品。
      • @samoz 我没有对有/没有和 IDE 的程序员效率做出任何断言(这些研究已经完成),只是指出 vim 和 emacs 不是 IDE,这是作者提出的问题。如果您使用过 Xcode,您应该知道它支持极其灵活的键绑定和脚本,而且我所知道的最好的 Xcode 编码器只需要很少的鼠标点击。当他们这样做时,通常用于项目构建配置,我敢打赌这比在 vim/emacs 中调整 makefile 更快。
      • @samoz:我使用 Xcode,我不会花大部分时间点击鼠标。我大部分时间都在思考。
      【解决方案7】:

      Xcode 确实有一些上下文感知,当你向一个对象发送消息时,它通常会让“ESC”列表拉出有意义的参数。

      我强烈推荐的一件事是查看文本宏。这些并不是真正的类型感知,但它们可以节省大量的输入——例如,在@implementation 类型“init”然后点击控制之后。 (句点)激活文本宏。它将为您填写完整的 init 方法。您可以创建自己的宏,或覆盖现有的宏。

      【讨论】:

        猜你喜欢
        • 2010-12-29
        • 1970-01-01
        • 2010-10-13
        • 2015-04-06
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-09-18
        • 1970-01-01
        相关资源
        最近更新 更多